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The  Computer  Aided  Function-Allocation  Evaluation  System  (CAFES)  is  being 
developed  by  The  Boeing  Aerospace  Company  under  contract  to  the  Naval  Air 
Development  Center  (Warminster,  Pa.).  To  date,  five  phases  have  been  com- 
pleted: Concept  Formulation  (Phase  I);  Function  Allocation  Model  (FAM) 

and  Data  Management  System  (DMS)  (Phase  II);  Workload  Assessment  Model  (WAM) 
(Phase  III);  Computer-Aided  Design  (CAD)  Model  (Phase  IV);  and  development 
of  selected  interfaces  between  CAFES  and  the  Crewstation  Geometry  Evaluation 
(CGE)  Model  (Phase  V).  During  Phase  VI,  major  emphasis  will  be  placed  upon 
completion  of  all  initial  CAFES  developments,  transition  of  the  CAFES  soft- 
ware from  a research  and  development  status  to  a production  level  status,  and 
delivery  and  installation  of  the  CAFES  submodels  to  the  NADC  computing  facility 
at  Warminster,  Pa. 

This  report  documents  the  results  of  Phase  V work  conducted  under  Naval  Air 
Development  Center  Contract  No.  N62269-75-C-0239  (10  March  1975  through 
10  March  1976).  The  Phase  IV  documents  contained  a summary  of  all  CAFES 
developments  through  31  December  1974.  Therefore,  this  report  will  only 
cover  CAFES  developments  that  have  transpired  since  the  Phase  IV  Program. 

The  authors  would  like  to  express  their  appreciation  for  the  contributions 
made  by  the  following  people: 

1)  CDR  R.  J.  Wherry,  Jr.,  Naval  Air  Development  Center  for 
valuable  suggestions  on  human  performance  modeling  in 
general  and  the  contributions  made  by  his  Human  Operator 
Simulator  and  the  CUBITS  panel  space  optimization  concept 
in  particular, 

2)  Mr.  Christian  Skriver  as  Naval  Air  Development  Center  tech- 
nical monitor  who  provided  valuable  guidance,  encouragement 
and  contributions  to  initial  conceptual  developments  through- 
out the  project. 

3)  LCDR  P.  Chatelier  who  has  continued  to  provide  funding  support, 
program  guidance,  and  technical  contributions. 
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ABSTRACT 


This  report  documents  Phase  V accomplishments  in  a continuing  program  to 
develop  the  Computer-Aided  Function  Allocation  and  Evaluation  System  (CAFES) 
CAFES  is  a crew  systems  design  support  system  based  on  human  engineering 
methods,  computer  aids,  human  performance  data,  and  a data  management  system 
It  is  intended  to  support  crew  systems  engineers  in  systems  development  from 
initial  mission  and  requirements  analysis  through  design,  test,  training  and 
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maintenance  systems  development,  as  well  as  in  the  definition  of  man-machine 
research  needs. 

The  present  report  describes  the  CAFES  developments  that  have  transpired  since 
the  Phase  TV  Program.  These  developments  included:  (1)  completion  of  the  mili- 
tary specifications  and  standards  data  sets  (MILSTAN)  that  are  used  for  check- 
ing the  compliance  of  crewstations  against  military  specifications  and  stan- 
dards applicable  to  two-place  fixed-wing  aircraft;  (2)  completion  of  a CAD/CGE 
Interface  Module  for  the  automatic  transfer  of  crewstation  geometry  data  from 
the  Computer  Aided  Design  Model  to  the  Crewstation  Geometry  Evaluation  Computer 
Program  System;  (3)  an  analysis  of  the  current  status  and  the  development  poten- 
tial of  the  CGE  Reach  Basket  Model;  and  (4)  completion  of  a DMS/CGE  Interface 
Module  to  provide  for  input,  execution  and  output  of  Crewstation  Geometry  Evalu- 
ation data  via  the  CAFES  Data  Management  System.  The  Phase  V document  also  in- 
cludes a discussion  of  the  preliminary  design  specification  for  a CONsole  Space 
Optimization  and  Layout  Evaluation  (CONSOLE)  Model,  and  the  CAFES  Phase  VI  pro- 
gram plan. 
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This  report  documents  all  work  accomplished  during  the  CAFES  Phase  V Program. 

The  report  is  divided  into  nine  major  sections:  (1)  completion  of  the  military 
specifications  and  military  standards  (MILSTAN)  data  set;  (2)  development  of 
an  interface  module  between  the  Computer  Aided  Design  (CAD)  Model  and  the  Crew- 
station  Geometry  Evaluation  Computer  Program  System  (CGECPS);  (3)  analysis  of 
the  CGE  Reach  Basket  Model;  (4)  development  of  an  interface  module  between  the 
Data  Management  System  (DMS)  and  the  CGECPS;  (5)  development  of  a preliminary  de- 
sign specification  for  a CONsole  Space  Optimization  and  Layout  Evaluation 
(CONSOLE)  Model;  (6)  plans  for  CAFES  validation  and  implementation;  (7)  re- 
structure of  CAFES  documentation;  (8)  integration  plan  for  CAFES  submodels; 
and  (9)  the  CAFES  Phase  VI  program  plan.  Since  the  entire  Phase  V report  is 
contained  within  one  volume,  information  relevant  to  both  the  user  and  the 
programmer  is  contained  within  each  section  dealing  with  software  development. 
Additional  detailed  information  concerning  program  documentation  and  sample  prob- 
lems is  contained  in  the  Appendices. 

The  first  section  deals  with  work  that  was  performed  to  complete  the  military 
specifications  and  military  standards  (MILSTAN)  data  set.  This  data  set  is 
used  for  checking  the  compliance  of  crewstation  configurations  against  mili- 
tary specifications  and  standards  relevant  to  two-place  fixed-wing  aircraft. 

To  complete  the  MILSTAN  data  set,  vector  geometry  for  44  new  analytic  func- 
tions was  coded  and  input  to  the  previous  MILSTAN  data  set.  Then,  the  new 
MILSTAN  data  set  was  executed  against  the  A-7E  aircraft  to  verify  the  new 
tests  and  to  recheck  the  original  tests.  An  error  in  the  Geometric  Object 
Manipulation  Program  (GOMP)  and  several  errors  in  the  previously  used  A-7E 
and  MILSTAN  data  sets  were  discovered  and  corrected.  A description  of  these 
errors  is  included  in  the  MILSTAN  section  along  with  recommendations  for  possible 
improvements  to  the  GOMP  program  that  would  enhance  both  the  efficiency  of  the 
crewstation  compliance  checking  procedure  and  the  readability  of  the  MILSTAN 
test  results.  Finally,  the  MILSTAN  section  contains  a detailed  discussion  of 
the  procedures  to  be  used  when  future  revisions  of  the  MILSTAN  data  set  are 
required . 

Section  two  contains  a description  of  the  interface  module  that  was  developed 
between  the  Computer  Aided  Design  (CAD)  Model  and  the  Crewstation  Geometry 
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Evaluation  (CGE)  computer  program  system.  The  CAD/CGE  interface  module  was 
developed  so  that  the  flexibility  of  data  input  inherent  in  the  CAD  Model 
could  be  applied  to  selected  programs  within  the  CGE  system.  The  CAD/CGE 
interface  module  provides  a means  of  formatting  CAD  output  geometry  so  that 
a crewstation  design  can  be  input  directly  to  CGE  for  analysis  of  reach  infeasi- 
bilities or  to  test  for  compliance  with  military  specifications  and  standards. 

A description  of  user  inputs,  model  outputs,  CAD/CGE  interface  logic  and  data 
bank  categories  is  contained  in  this  section. 

A review  of  the  present  status  of  the  CGE  Reach  Basket  Analysis  program  is  con- 
tained in  section  three.  The  Reach  Basket  Analysis  program  was  examined  to  ob- 
tain an  estimate  of  the  resources  that  would  be  required  to  complete  the  model. 

Particular  emphasis  is  placed  upon  a reduction  in  the  amount  of  core  memory  and 
in  the  amount  of  execution  time  required  by  the  model.  A discussion  is  also  pro- 
vided on  the  background  and  source  of  the  Reach  Basket  Analy~is  program  and  the 
link-system  tree  structure  that  is  used  in  the  model. 

The  fourth  section  contains  a description  of  the  interface  that  was  developed 
between  the  Data  Management  System  (DMS)  and  the  Crewstation  Geometry  Evalua- 
tion (CGE)  computer  program  system.  The  DMS /CGE  interface  module  was  developed 
to  allow  the  CGE  user  to  employ  DMS  capabilities  for  inputting  cockpit  plane 
and  control  definitions,  control  shape  data  and  task  sequence  data  into  the  CGE 
system.  This  section  contains  a description  of  the  execution  and  report  commands 
that  were  incorporated  under  the  CAFES  executive  as  well  as  a set  of  A-7E  data 
that  was  input  to  the  DMS  to  demonstrate  CGE  input,  execution  and  output  via 
the  CAFES  DMS. 

Section  five  describes  a preliminary  design  specification  for  a CONsole  Space 
Optimization  and  Layout  Evaluation  (CONSOLE)  Model.  The  specification  provides 
a broad  outline  of  desired  capabilities  and  a set  of  specific  requirements  for 
an  initial  conceptualization  of  the  CONSOLE  Model.  The  specification  includes 
a description  of  the  general  requirements  and  objectives  of  the  model,  the  con- 
cept of  the  model,  and  the  input  requirements,  computing  routines  and  outputs 
of  the  model. 

Plans  for  CAFES  validation  and  implementation  are  discussed  in  section  six.  The 
implementation  plan  deals  with  the  CAFES  delivery  schedule,  verification  tests 
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to  be  performed  at  the  NADC  computing  facility  and  the  presentation  of  in- 
formal training  to  acquaint  NADC  personnel  with  the  CAFES  models.  The  vali- 
dation plan  describes  requirements  for  the  effective  utilization  of  the  CAFES 
programs  at  NADC. 

Section  seven  contains  a discussion  of  the  continuing  effort  to  modularize  and 
integrate  the  CAFES  documentation  into  a pair  of  separate  self-contained  vol- 
umes for  each  of  the  CAFES  models.  A preliminary  organizational  scheme  for 
the  final  CAFES  documentation  is  presented  in  this  section. 

A detailed  plan  for  the  integration  of  the  CAFES  models  with  the  CGE  and  the 
Human  Operator  Simulator  (HOS)  is  presented  in  section  eight.  Several  poten- 
tial data  interfaces  between  the  three  computer  programs  are  identified  and 
discussed  in  this  section. 

Section  nine  contains  a description  of  the  CAFES  Phase  VI  Program  Plan.  Major 
emphasis  is  placed  upon  software  refinements  and  documentation  in  anticipation 
of  routine  production  runs  following  delivery  and  installation  at  NADC.  The 
following  tasks  are  discussed  in  section  nine:  completion  of  submodel  inte- 
gration; completion  of  submodel  efficiency  improvements;  completion  of  user 
interface  improvements;  completion  of  system  documentation;  completion  of  CAD 
Model  developments;  preparation  of  CAFES  training  material,  development  of  con- 
figuration control  system  and  procedures;  and  delivery  and  installation  of 
CAFES  to  NADC. 
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2.0  COMPLETION  OF  MILITARY  SPECIFICATIONS  AND  STANDARDS  COMPLIANCE  TESTS 


Analytic  functions  (vector  geometry  and  geometric  tests)  for  comparing 
and  evaluating  crewstation  configurations  with  respect  to  military  specifica- 
tions and  standards  were  developed  during  Phase  III  of  the  Cockpit  Geometry 
Evaluation  (CGE)  Program.  Fourteen  separate  military  specifications  and 
standards  were  examined  to  determine  which  specific  requirements  would  be 
applicable  for  an  automated  compliance  checking  routine.  Computer  tests  for 
many  of  these  specifications  were  designed  and  coded  but  CGE  development  was 
terminated  before  this  task  was  completed.  One  objective  of  the  CAFES  Phase 
V Program  was  to  complete  the  development  of  all  analytic  functions  for 
checking  crewstation  configurations  against  military  specifications  and 
standards  relevant  to  military  aircraft  cockpits. 

All  military  specifications  and  standards  applicable  to  two-place 
fixed-wing  aircraft  have  been  coded  and  input  to  the  CGE  program.  Several 
tasks  were  involved  in  completing  the  analytic  functions.  First,  all 
previously  developed  analytic  functions  were  reviewed  to  determine  if  the 
existing  functions  required  modification  or  if  new  geometric  tests  were 
required.  The  review  indicated  that  all  of  the  tests  had  been  fully 
completed  for  eight  of  the  fourteen  specifications  and  standards  (MS33573, 
MS33574,  MS33575,  MS33576,  MIL-STD-18471D,  MIL-STD-411D,  MIL-STD-850B, 
MIL-B-8584C) . Of  the  six  remaining  specifications  and  standards,  two  did 
not  contain  testable  requirements  applicable  to  fixed-wing  aircraft  (MIL- 
STD-250C  and  MIL-H-46855)  and  four  required  development  of  additional 
analytic  functions  (MIL-STD-1333A,  MIL-STD-203E,  MIL-S-9479B,  and  MIL-STD- 
1472A) . 

A total  of  44  new  compliance  tests  were  completed  during  Phase  V. 

Then,  a series  of  specification  compliance  tests  for  the  A-7E  aircraft 
were  designed  and  executed  to  verify  the  new  tests  and  to  recheck  the 
original  tests.  In  conducting  these  tests,  an  error  was  discovered  in 
the  original  CGE  coding.  This  error  has  been  corrected  and  the  software 
tapes  have  been  updated.  The  content  and  format  of  the  output  reports 
from  the  new  specifications  and  standards  compliance  tests  are  consistent 
with  the  format  used  in  the  original  CGE  Program. 

The  following  section  contains  documentation  that  describes  how  the 
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military  specifications  and  military  standards  (MILSTAN)  data  set  can  be 
updated  and  how  the  vector  geometry  subroutines  of  the  Geometric  Object 
Manipulation  Program  (GOMP)  can  be  used  to  perform  military  specifications 
and  standards  compliance  checks.  A discussion  of  the  GOMP  design  philosophy 
as  it  applies  to  military  specifications  and  standards  checks  is  also 
included  in  this  section. 

2.1  Procedure  for  Revising  MIL-STDS/MIL-SPECS  Tests  in  the  GOMP/MILSTAN 
Computer  Program/Data  Base  System 

The  GOMP/MILSTAN  Computer  Program/Data  Base  System  consists  of  a 
computer  program,  GOMP  (Geometric  Object  Manipulation  Program),  and  two 
data  sets;  (a)  coded  MIL-STDS/MIL-SPECS  on  a file  which  is  referred  to  as 
MILSTAN  in  all  applicable  documents,  and  (b)  the  user's  input  geometry 
describing  the  aircraft  crewstation  being  tested.  The  coded  MIL-STDS/ 
MIL-SPECS  in  the  MILSTAN  data  set  are  actually  a sequence  of  coded  instruc- 
tions in  a format  which  GOMP  recognizes.  A separate  data  set,  in  addition 
to  MILSTAN,  contains  the  user-supplied  crewstation  geometry  which  is  to 
be  compliance-tested  versus  the  MIL-STDS/MIL-SPECS  which  are  "coded  into" 
MILSTAN.  When  this  geometry  data  set  and  MILSTAN  are  supplied  together 
as  input  to  GOMP  (Figure  1),  the  result  is  a computer-generated  list  of  test 
results  for  the  user-supplied  geometry. 

The  geometry  data  set  consists  partly  of  simple  coded  instructions  and 
partly  of  3-space  geometry  data  in  a simple  format  which  describes  the 
user's  crewstation  design.  The  coded  instructions  are  interspersed  with 
the  geometry  data  and  are  in  a format  similar  to  the  MILSTAN  coded 
instructions.  However,  the  only  purpose  of  the  coded  instructions  in  the 
geometry  data  set  is  to  instruct  GOMP  to  read  and  store  the  geometry  data 
and  organize  it  as  required  for  compliance-testing  via  the  coded  MILSTAN 
instructions.  The  following  discussion  assumes  a basic  familiarity  with  the 
GOMP  and  the  MILSTAN  elements  of  the  CGE  Computer  Program  System. 

2.1.1  The  Geometry  Data  Set 

Points,  lines  and  planes  can  be  read  and  stored,  and  segment 
boundaries  (e.g.,  a plane  segment  with  a polygonal  boundary)  can  be  indicated. 
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This  is  done  by  reading  in  two  points  for  a line  or  line  segment,  or 
from  three  to  six  points  for  a plane  or  plane  segment.  GOMP  automatically 
computes,  using  the  input  points,  a direction  vector  for  each  input  line 
and  a normal  vector  for  each  input  plane.  The  format  for  these  data  consists 


(a)  an  8-character  name,  plus  three  coordinates  for  points, 

(b)  an  8-character  name,  plus  two  vertices  (three  coordinates  per 
vertex)  for  lines,  and 

(c)  a 30-character  description  followed  by  an  8-character  name, 
followed  by  an  integer  from  3 to  6 indicating  the  number  of 
vertices  for  planes.  For  each  plane,  this  is  followed  by  the 
coordinates  for  the  vertices. 

A fourth  type  of  data  is  defined  by  the  user  with  a geometry  data  set 
instruction  which  has  been  provided  for  the  purpose  of  organizing  groups 
of  points,  lines  or  planes  into  logical  units.  These  logical  units  are 
called  composites  and  they  are  used  by  the  GOMP/MILSTAN  system  to  con- 
veniently access  groups  of  geometric  objects  for  compliance  testing. 

These  composites  (or  composite  objects)  are,  in  fact,  one  of  the  main 
features  of  the  GOMP  capability  and  are  essential  in  most  of  the 
MIL- STDS /MIL-SPECS  tests  coded  into  MILSTAN. 

The  format  for  a composite  definition  in  the  geometry  data  set  is  very 
simple.  An  8-character  name  for  the  composite  is  read  in,  followed  by  the 
names  of  the  geometric  objects  to  be  included  in  the  composite.  The  objects 
must  have  been  read  into  storage  prior  to  the  execution  of  the  composite 
definition  instruction  (see  COMPOSE  instruction,  Reference  2 ) and  the 
objects  must  all  be  of  the  same  type,  points,  lines  or  planes.  Objects  which 
are  named  in  the  composite  definition,  but  for  which  GOMP  has  received  no 
data,  will  simply  be  omitted  from  the  composite,  with  a printed  message  to 
inform  the  user. 
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A list  of  "standard  names"  for  points,  lines,  planes  and  composites  is 
presented  in  Reference  2 . New  names  are  added  to  this  list  whenever  the 
MILSTAN  test  instruction  data  set  is  expanded  to  include  more  MIL-STDS/ 
MIL-SPECS  compliance  tests.  If  a point,  line  or  plane  does  not  have  one  of 
these  standard  names,  it  must  be  included  in  a composite  with  a standard 
name  via  a composite  definition  instruction  occurring  in  the  user's  geometry 
data  set.  Otherwise,  it  will  not  be  referenced  for  use  in  any  of  the 
compliance  tests  during  execution  of  GOMP  and  its  inclusion  in  the  geometry 
data  set  will,  hence,  be  superfluous.  A composite  must  have  one  of  the 
standard  composite  names  or  it  will  not  be  referenced  in  any  of  the  MILSTAN 
tests. 

2.1.2  Geometric  Storage  Access 

Program  GOMP  reads  the  geometry  data  (including  the  composite  definitions) 
and  then,  on  encountering  the  instruction  "GO"  at  the  end  of  the  geometry 
data  set,  switches  to  the  MILSTAN  input  file  to  begin  executing  the  compliance 
tests.  The  compliance  test  instructions  coded  into  MILSTAN  are  then 
executed  sequentially  as  they  occur  in  the  MILSTAN  data  set.  Each  test 
instruction  references  geometric  or  composite  objects  by  name,  using  the 
standard  names  referred  to  earlier. 

The  geometry  referenced  by  the  MILSTAN  test  instruction  being  executed 
is  called  from  the  applicable  central  geometric  storage  array  (one  for 
points,  one  for  lines  and  one  for  planes)  into  a compact  storage  area 
known  as  a MILSTAN  register . In  central  geometric  storage,  the  geometric 
objects  are  referenced  indirectly  via  table  lookup  on  names  (Figure  2). 

Whenever  a composite  is  used  in  a test,  the  referencing  of  geometric  objects 
in  the  composite  is  doubly  indirect  because  the  table  lookup  is  performed 
to  locate  the  composite  by  name.  The  objects  within  the  composite  are 
then  referenced  indirectly  in  a staged  array  process  (Figure  3).  Once  the 
objects  have  been  loaded  into  a MILSTAN  register,  however,  they  are  referenced 
directly  as  needed  in  the  calculations  performed  by  GOMP  to  execute  the 
current  MILSTAN  test  instruction. 
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Figure  3.  Geometric  Storage  Access  by  Composite  Object  Name 
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2.1.3  The  MILSTAN  Data  Set 


A MILSTAN  test  instruction  consists  of  three  basic  types  of  instructions 
for  GOMP  which  are  executed  in  sequence,  viz.:  (a)  OPERATE,  (b)  TEST,  and 

(c)  FORMAT.  The  first  instruction,  or  instruction  sequence,  consists  of  one 
or  more  OPERATE  instructions  which  call  the  appropriate  geometry  into  a 
MILSTAN  register  and  perform  operations  on  the  geometry  to  get  numerical 
test  results.  Following  one  or  more  OPERATE  instructions,  one  or  more  TEST 
instructions  are  used  to  perform  the  MIL-STDS /MIL-SPECS  compliance  test 
against  some  test  criterion  using  the  numerical  results  from  the  OPERATE 
instruction(s) . Finally,  one  or  more  FORMAT  instructions  will  cause  the 
test  results  to  be  printed  out  in  a specified  format.  The  following  examples 
show  input  data  in  card  image  format  where  all  items,  except  for  the  output 
format,  are  left  justified  in  a ten  column  field. 

Example  1 

The  MS33574  test,  "Design  Eye  Point  must  be  31.5  inches  above  Neutral 
Seat  Reference  Point",  is  performed  with  the  following  instructions  to 
GOMP  in  the  MILSTAN  data  set: 

AND 

OPERATE 
DIST 
NUTRLSRP 
TEST 
GE 
AND 
TEST 
LE 

FORMAT 

DEP  MUST  BE  31.5  IN.  ABOVE  NUTRLSRP 
* 

PRT  SUCCESS  PASS  TOL 


ABOVE 

DEP  * 

31.437 

31.563 


r 


In  this  case,  there  is  only  one  OPERATE  instruction.  It  consists  of 
the  lines 

OPERATE 

DIST  ABOVE 

NUTRLSRP  DEP  * 

The  "DIST  ABOVE"  line  is  interpreted  as  the  distance  of  a point  above 
a reference  point.  In  this  case,  the  distance  of  DEP  (design  eye  point) 
above  NUTRLSRP  (neutral  seat  reference  point)  is  to  be  found.  The  * indicates 
the  end  of  the  list  of  objects  to  be  operated  on.  The  operation  is  performed 
by  subtracting  the  Z (/ertical)  coordinate  of  NUTRLSRP  from  that  of  DEP,  where 
the  "up"  direction  is  that  of  increasing  Z.  Thus,  distance  above  is 
positive  or  negative  depending  on  whether  DEP  is  above  or  below  NUTRLSRP. 

Two  important  points  to  note  here  are: 


i 

. 


(a)  GOMP  assumes  a certain  coordinate  system  orientation,  although 

the  coordinate  origin  is  determined  entirely  in  the  numerical 
data  for  the  user's  geometry.  The  orientation  is:  positive  X 

is  to  the  right  of  the  crewstation,  positive  Y is  forward,  and 
positive  Z is  straight  up. 

(b)  It  is  not  specifically  mentioned  in  the  OPERATE  instruction 
that  NUTRLSRP  and  DEP  are  points.  GOMP  discovers  this  for 
itself  after  table  look-up  in  the  Geometric  Object  Definition 
Array  (GODA)  to  find  the  locations  of  the  geometric  objects 
named  NUTRLSRP  and  DEP  in  central  geometric  storage  (see 
Figure  2) . 

Part  of  the  information  in  GODA  specifies  the  geometric  type  (GX  for 
points,  GL  for  lines,  GP  for  points)  of  each  object.  This  tells  which 
storage  array  contains  the  numerical  data  for  the  object  and  which  type  of 
operation  to  perform.  Although  there  is  no  DIST  ABOVE  operation  for  other 
than  points,  suppose  the  operation  had  been  coded  in  MILSTAN  as  DIST  FROM. 
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In  this  case,  there  are  many  possibilities  provided  by  GOMP.  If  the  objects 
are  planes,  there  is  a plane/plane  distance  operation  provided,  and  for 
points  there  is  point/point  Eculidean  distance.  If  one  object  is  a point 
and  the  other  a plane,  there  is  point/plane  perpendicular  distance.  If  both 
objects  are  plane  segments  (in  which  case  the  2nd  line  would  read  "DIST 
FROM  SS").  the  operation  performed  is  to  find  the  minimum  separation  of 
the  point-sets  enclosed  by  the  polygonal  boundaries  enclosing  the  two  plane 
segments.  And  so  on.  Hence,  the  geometric  type  of  each  geometric  object 
must  be  available  from  the  GODA  array  not  only  for  storage/retreival  but 
for  branching  to  the  appropriate  operation  logic. 


In  the  MILSTAN  test  being  discussed,  the  next  set  of  GOMP  instructions 


consists  of 


31.437 


31.563 


separated  by  the  logical  connector  AND;  note  also  the  AND  at  the  very 
beginning  of  this  MILSTAN  test.  Usually  a sequence  of  TEST  instructions 
or  OPERATE/TEST  combinations  are  joined  by  AND  connectors  if  they  belong 
to  the  same  MILSTAN  test.  The  final  test  results  are  then  the  logical 
conjunction  of  the  individual  tests  which  are  connected  by  AND's.  In  the 
above  example,  the  numerical  result  from  the  DIST  ABOVE  operation  will 
have  passed  the  overall  MILSTAN  test  if  it  is  (a)  greater  than  or  equal  to 
31.437  AND  (b)  less  than  or  equal  to  31.563. 


If  there  is  only  one  operation  followed  by  several  tests,  the 
general  form 


OPERATE 


4 


AND 

TEST 

AND 

TEST 

AND 

TEST 


AND 

TEST 


can  be  used  - the  first  AND  must  precede  the  first  TEST.  If  more  than  one 
operation  is  to  be  performed  using  the  same  objects,  the  general  form  is 

AND 

OPERATE 

refnamel  namel  name2 

TEST 

AND 

OPERATE 

ref name 2 USE  * 

TEST 

AND 

OPERATE 
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USE  * 


AND 

OPEftATE 
ref namen 
TEST 


the  object  names  refnamel,  refname2,  etc.  denote  reference  objects  and 
namel,  name2,  etc.  are  the  objects  being  tested  for  compliance  (the  test 
objects).  In  most  MILSTAN  tests,  a reference  object  is  required,  e.g.  if 
namel,  name2,  ...  are  points  (controls)  being  tested  for  compliance  with 
some  standard  clearance  envelope  around  the  DEP,  then  refnamel  is  DEP.  The 
operation  performed  would  be  point/point  distance,  to  find  the  distance  of 
each  point  namel,  name2 from  refnamel,  viz.: 

OPERATE 

D1ST  FROM 

refnamel  namel  name2  ...  * 

Subsequent  test  may  use  different  reference  objects  but  must  use  the 
same  test  objects  namel,  name2,  etc.  To  re-use  the  same  test  objects,  which 
are  still  conveniently  stored  in  MILSTAN  registers  following  the  first 
OPERATE  instruction,  the  USE  * indicator  is  used, 

OPERATE 

refname2  USE  * 
and  so  on. 

This  discussion  has  wandered  somewhat  from  Example  1,  but  it  has 
served  to  illustrate  the  practical  use  of  the  AND,  OPERATE,  and  TEST 
instructions  in  sequence.  Also,  the  re-use  of  test  objects  via  USE  * and 
the  introduction  of  the  concepts  of  test  object  and  reference  object  have 
been  delineated. 

To  get  back  to  Example  1,  once  the  TEST  instructions  have  been 
executed,  GOMP  has  stored  the  operational  result  of  the  DIST  ABOVE 
operation  in  one  of  two  tables:  (a)  the  PASS  table  if  the  distance 
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of  DEP  above  NUTRLSRP  lies  between  31.437  and  31.563,  or  (b)  the  FAIL 
table  if  the  distance  lies  outside  this  range.  Using  a FORMAT  instruction, 
the  final  test  result  can  be  printed  out  by  COMP  using  the  information  from 
the  PASS  and  FAIL  tables. 

Had  there  been  several  test  objects  (instead  of  the  single  object  DEP), 
the  operational  results  for  the  different  objects  could  be  divided  between 
the  two  tables,  and  there  would  be  indicators  to  show  which  objects  belonged 
to  each  operational  result.  Thus,  a list  of  objects  which  pass  the  test 
(or  tests)  and  a list  of  objects  which  fail  the  test(s)  are  available, 
along  with  corresponding  numerical  operational  results  (e.g.,  point/point 
distances) . 

GOMP  output  of  this  information  requires  use  of  the  FORMAT  instruction. 

Following  the  FORMAT  input  line,  subsequent  80  character  lines  are  printed 
exactly  as  they  appear  until  a * is  encountered  within  the  first  ten  columns 
of  a line.  The  next  line  can  start  with  any  kind  of  instruction  (OPERATE,  i 

TEST,  etc.),  but  usually  a PRT  (for  "print")  instruction  is  needed.  The  lines 
between  FORMAT  and  * (and  there  need  not  be  any)  can  be  used  to  provide  a 
readable  title  for  the  MILSTAN  test.  However,  it  requires  a PRT  instruction 
to  get  the  test  results  printed  (the  PRT  must  be  preceded  by  a FORMAT  which 
need  not  contain  any  input  line  before  the  *) . 


In  the  line 

PRT  SUCCESS  PASS  TOL 

the  word  SUCCESS  indicates  a full  printout  of  test  results  in  a readable 
phrase  e.g. 

THE  FOLLOWING  OBJECT  DOES  NOT  SATISFY  DIST  ABOVE  NUTRLSRP  EQ 
31.5  TOLRNCE  .063 

The  word  PASS  has  no  effect  when  SUCCESS  is  present  - it  is  included  for 
consistency  and  must  be  present.  The  word  TOL  instructs  GOMP  to  treat  the 
result  of  the  two  tests  (GE  31.437  and  LE  31.563)  in  the  following  manner: 
the  average  of  31.437  and  31.563  (=  31.5)  is  the  actual  criterion  and  this 
MTLSTAN  test  should  be  treated  as  an  equality  test  with  an  associated 
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tolerance  value  ([31.437  - 31.563|/2  = .063).  Thus  the  compliance  test 
result,  as  shown  by  the  sample  printout  above,  is  judged  successful  if  the 
distance  above  the  reference  object  NUTRLSRP  is  within  .063  inches  of  31.5 
inches. 

If  only  a single  TEST  instruction  is  executed  in  the  MJ.LSTAN  compliance 
test,  or  if  each  of  a sequence  of  TESTs  is  followed  by  a FORMAT  instruction, 
the  word  TOL  need  not  appear. 

Example  2 (MS33574) 

OPERATE 
DIST 

NUTRLSRP 
TEST 
LE 

FORMAT 

MAX  FWD 
* 

PRT 
TEST 
LE 

FORMAT 

MAX  FWD  THROTTLE  - CATAPULT  AIRCRAFT 
* 

PRT  SUCCESS  PASS 

In  this  example,  only  one  OPERATE  is  to  be  executed  (a  single 
operation,  point/point  distance,  is  to  be  performed).  There  will  be  two 
tests  performed  on  the  operational  results  from  the  OPERATE  execution. 
However,  instead  of  requiring  the  numerical  operational  result  (point/ 
point  distance  between  NUTRLSRP  and  THRTFWD)  to  satisfy  both  tests  to 
get  a final  test  result  as  in  the  case  of  Example  1,  each  test  will  be 


THROTTLE  - NON-CATAPULT  AIRCRAFT 
SUCCESS  PASS 
20. 


FROM 

THRTFWD  * 
25. 


k 


a separate  test  of  the  same  operational  result.  This  is  indicated  by  (a) 
the  absence  of  any  AND  connectors  and  (b)  the  presence  of  a FORMAT 
instruction  with  an  associated  PRT  instruction  following  each  test. 

Hence,  each  of  the  two  tests  in  this  example  is  performed  indepen- 
dently (and  is  only  half  of  the  total  compliance  test  being  performed). 

There  is  no  need  for  the  TOL  part  of  the  PRT  command  (in  fact,  its 
inclusion  would  be  erroneous),  but  the  presence  of  "SUCCESS  PASS"  provides 
a readable  test  result  for  each  test,  with  a format  identical  to  the  print- 
out of  Example  1 (the  tolerance  will  be  zero) . 

For  some  compliance  tests,  the  formatting  of  test  results  for  print- 
out by  the  "PRr  SUCCESS  PASS"  form  is  insufficient,  and  for  these  cases 
the  formatting  should  be  done  largely  within  the  title  block  included  within 
the  range  of  the  FORMAT  instruction.  To  print  out  the  names  of  the  objects 
satisfying  the  test (s),  together  with  the  numerical  operational  results  in 
cases  where  the  user  provides  most  of  the  formatting: 

PRT  PASS  RES 

is  used.  If  printout  of  the  list  of  objects  failing  the  test  together 
with  operational  results  is  desired, 

PRT  FAIL  RES 

is  used. 

Example  3 . 

. 

In  this  example,  a part  of  the  MS33573  test  for  ejection  envelope 
clearance  for  the  pressure-suited  environment  is  presented.  The  total 
test  involves  locating  those  control  points  and  cockpit  panels  which  inter- 
fere with  the  ejection  envelope,  which  is  defined  from  the  user's  input 
geometry  by  a combination  of  standard  input  planes  SEJPN  and  the  design  eye 
point  X-coordinate  plane  (DEPXCP) . Only  the  part  of  the  test  dealing  with 
panels  will  be  shown.  The  MILSTAN  test  instructions  are: 
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FORMAT 


ANY  PANEL  CONTAINED  IN  THE  LAST  OF  THE  FOLLOWING  FOUR 
LISTS  IS  INSIDE  THE  EJECTION  ENVELOPE  FOR  THE  PRESSURE- 
SUITED  ENVIRONMENT 

* 

AND 

OPERATE 

DIST  FROM  S 

SEJPN  COMPOSITE  ALLPAN 

TEST 

GE  0. 

FORMAT 

LIST  1.  PANELS  FORWARD  OF  SEJPN 
PANEL  DIST (IN.) 


PASS  RES 


FROM  S 

USE  * 

30. 


LIST  2.  PANELS  FROM  LIST  1.  LYING  AFT  OF  EJ. 
ENV.  FRONTAL  PLANE 
PANEL  DIST (IN.) 

* 

PRT  PASS  RES 

AND 

OPERATE 


* 

PRT 

AND 

OPERATE 

DIST 

SEJPN 

TEST 

LE 

FORMAT 


19 


I'. 


FROM  S 

USE  * 

-15. 


LIST  3.  PANELS  FROM  LISTS  1.  AND  2.  LE  15  IN. 
LEFT  OF  DEP 
PANEL  DIST(IN. ) 

PASS  RES 


FROM  S 

USE  * 

15. 


LIST  A.  THE  PANELS  IN  THIS  LIST  VIOLATE  EJ . 
ENV.  CLEARANCE  FOR  THE  PRESSURE- 
SUITED  ENVIRONMENT 
PANELS  DIST(IN. ) 


PRT  PASS  RES 

Note  that  A operations  are  performed,  all  using  the  same  set  of  test 
objects.  The  test  objects  are  the  crewstation  panels,  which  the  user  has 
grouped  into  composite  ALLPAN  during  the  geometry  input  phase  using  the 


S 

1PRT 
AND 

[OPERATE 
DIST 
DEPXCP 
TEST 
LE 

FORMAT 


DIST 

DEPXCP 

TEST 

GE 

FORMAT 


COMPOSE  instruction.  Note  that  only  the  first  OPERATE  instruction  names 
the  composite,  and  the  subsequent  operations  contain  USE  * in  place  of 
the  name  COMPOSITE  ALLPAN  (which  need  not  be  followed  by  a *,  since  on 
seeing  the  word  COMPOSITE,  GOMP  knows  there  will  be  only  a single  name 
input).  During  the  first  operation,  GOMP  accesses  the  geometry  lying  within 
the  ALLPAN  composite  by  the  process  shown  in  Figure  3.  Thereafter,  the 
panels  in  ALLPAN  are  stored  compactly  in  a MILSTAN  register  for  quick 
access.  The  USE  * in  subsequent  operations  prevents  the  (Figure  3)  table- 
lookup  and  staged  access  process  from  being  repeated  for  each  operation. 

In  addition,  the  OPERATE/TEST  instruction  pairs  of  the  example  are  connected 
by  ANDs,  and  the  USE  * is  absolutely  necessary  for  the  AND  connectors  to 
have  their  intended  effect. 

Following  execution  of  each  OPERATE,  geometric  storage  indices  for 
those  panels  which  fail  the  following  test  and  moved  from  the  PASS  table 
(which  initially  contains  the  indices  of  all  the  panels  in  ALLPAN)  to  the 
FAIL  table.  The  AND  connectors  (together  with  USE  *)  cause  subsequent 
OPERATE/TEST  failures  to  be  moved  from  the  PASS  table  to  the  FAIL  table, 
adding  to  those  indices  already  in  the  FAIL  table.  Thus,  an  object  (in  this 
case  a panel)  must  pass  each  test  in  order  to  remain  in  the  PASS  table,  or 
must  fail  at  least  one  test  in  order  to  be  moved  to  the  FAIL  table. 

In  the  example,  the  panels  which  have  passed  all  previous  AND-connected 
OPERATE/TEST  tests  are  those  left  in  the  PASS  table.  Hence,  the  list  printed 
out  using  a FORMAT/PRT  combination  after  each  OPERATE/TEST  gets  successively 
smaller,  until  at  the  end  it  contains  only  those  panels  which  have  passed 
all  tests  (hence,  violate  ejection  envelope  clearance). 

Note  the  formatting  of  column  headings  provided  within  the  FORMAT  title 
block.  The  "PRT  PASS  RES"  instruction  causes  only  the  list  of  objects  from 
the  PASS  table,  with  associated  numerical  operational  results,  to  be  printed 
as  a two-column  table. 
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Note,  finally,  the  "S"  occurring  in  each  "DIST  FROM"  input  line.  Just 
as  "SS"  signifies  segment /segment  distance,  a single  "S"  signifies  that  only 
the  test  objects  are  to  be  treated  as  segments.  Since  the  two  reference 
objects,  SEJPN  and  DEPXCP,  are  stored  as  planes  (geometric  type  GP)  and  so 
are  the  test  objects  in  composite  ALLPAN,  the  operation  performed  is  that 
of  plane/plane-segment  distance.  This  is  defined  as  the  distance  of  closest 
vertex  of  the  plane  segment  to  the  plane.  It  has  zero  value  if  the  plane 
segment  intersects  the  plane.  It  is  a positive  value  if  the  plane  segment 
lies  in  the  direction  of  the  normal  to  the  plane  and  negative  if  the  plane 
segment  lies  on  the  opposite  side  of  the  plane.  Had  the  reference  object 
alone  been  a plane  segment  and  the  test  objects  infinite  planes,  an  "RS" 
would  have  been  used  in  place  of  the  "S" . 

2.1.4  Maintenance 

As  mentioned  in  the  introduction,  there  are  three  components 
necessary  to  the  execution  of  the  GOMP/MILSTAN  MIL-STDS/MIL-SPECS 
compliance  test  computer  system.  These  are  (a)  the  computer  program, 

GOMP,  and  the  data  base  components,  (b)  MILSTAN,  where  compliance  test 
instructions  for  GOMP  are  stored,  and  (c)  the  user’s  geometry  definitions 
(including  composites).  The  GOMP  program  is  maintained  and  updated  in 
FORTRAN  IV  source  code  form  using  the  BCS  MAINSTREAM-EKS  UPDATE  capability. 

The  MILSTAN  data  set  is  accessed  via  tape  or  from  permanent  file  but 
is  basically  maintained  as  a file  of  IBM  cards.  Whenever  the  MILSTAN 
instruction  set  is  altered,  a modified  set  of  cards  is  read  into  the 
computer,  and  a new  tape  or  disk  file  is  created  to  replace  the  old 
MILSTAN  file. 


The  user  crewstation  geometry  can  be  maintained  in  any  form,  and 
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MILSTAN  tests  performed  on  the  geometry.  These  objects  should  always  be 
included  in  the  user's  geometry  data  set,  although  no  single  object  is 
absolutely  necessary. 


2.2  Phase  V Work  on  the  GOMP/MILSTAN  System 

The  current  work  on  the  GOMP/MILSTAN  computer  program/data  base 
system  was  performed  to  improve  the  coverage  of  MIL-STD  and  SPEC  compliance 
checking  by  this  system.  A total  of  51  MIL-STDs/ SPECs  for  fixed  wing 
aircraft,  which  for  various  reasons  were  not  previously  included  on  the 
MILSTAN  test  instruction  data  tape,  were  analyzed  for  inclusion  as  coded 
tests  on  the  MILSTAN  tape.  Of  these,  44  tests  were  found  amenable  to  being 
coded  into  the  MILSTAN  data  file  using  the  present  capability  of  GOMP 
(Geometric  Object  Manipulation  Program).  These  44  tests  were  coded  and 
the  entire  MILSTAN  instruction  set  was  tested  using  an  augmented  A~7E  geometry 
data  set  for  checkout  data. 


In  addition  to  the  analysis  of  the  51  tests  to  be  added,  a review  of 
GOMP  program  capability  and  possible  improvements  was  performed.  Also,  an 
error  in  the  GOMP  computer  program  and  errors  in  the  previously-used  A-7E  and 
MILSTAN  data  sets  were  corrected. 


The  GOMP  error  was  in  the  calculation  of  the  distance  from  a point  P 
to  a convex  plane  segment  with  bounding  vertices  P^ , • ••,  P^.  Sub- 

routine DPTPNS  is  called  from  entry  point  D37  or  D73  of  subroutine  OISTXX 
to  perform  this  calculation.  First,  the  perpendicular  projection  P"  of  P 

on  the  plane  containing  P , P , ...  P is  found.  If  ?'  lies  within  the 

1 z N 

region  (P^ , •••♦  PN) » the  distance  ||p  - P'||  is  returned  (||*||  signifies 

3-space  Euclidean  norm).  If  P"  lies  outside  (P^,  ?2*  •••»  Pjj)  > the  distance 
] j P - P" | | is  returned,  where  P"  is  the  boundary  point  of  (P  , . ..,  PN) 

closest  to  P.  Originally,  P"  was  determined  as  the  projection  of  P onto  the 
nearest  edge  of  (P^,  P^,  ...»  P^) , say  (P^,  P^+j)-  However,  in  some  cases 
the  subroutine  returned  no  answer,  for  P"  was  determined  as  the  projection 
of  P onto  the  line  containing  the  edge  (P^,  pi+j)»  as  shown  in  Figure  4. 
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If  P"  could  not  be  found  to  lie  between  any  pair  of  adjacent  vertices,  no 
answer  was  returned  and  the  test  was  cancelled. 

The  correct  response  is  to  let  P"  be  the  nearest  vertex  if  P does  not 
project  onto  any  of  the  edges  (P1 , P^ , (P2>  P3),  (PN>  P^,  as  shown 

in  Figure  5.  This  was  implemented  in  subroutine  DPTPNS  and  correct  distances 
were  noted  in  the  tests  for  location  of  control  points  MAPSTOW  and  MAPST0W2 
on  the  left  and  right  consoles,  respectively  (this  is  one  of  the  newly-added 
MILSTAN  tests). 

In  addition,  some  of  the  old  tests  are  affected.  One  of  these  is  the 
head  clearance  requirement  at  the  beginning  of  MS33573.  One  of  the  A7E 
panels  now  violates  head  clearance.  Also,  the  MIL-STD-203E  tests  "throttle 
must  contain  speed  brake  control"  and  "seat  adjustment  on  seat"  are  now 
executed.  Previously,  the  message  "TEST  CANCELLED  - OBJECTS  NOT  DEFINED" 
was  printed  out  due  to  the  faulty  return  from  DPTPNS  described  above. 

The  total  revisions  made  to  program  GOMP  in  the  current  effort  are  as 
follows : 

(a)  Correct  the  error  in  the  point/plane-segment  distance 
calibration, 

(b)  Increase  storage  capability  for  3-space  points,  and 

(c)  Correct  a non-fatal  condition  which  produced  an  annoying 
"abnormal  termination"  message  at  the  end  of  a GOMP  execution. 

The  analysis  of  added  tests  is  outlined  in  Appendix  A.  Additional 
geometric  and  composite  objects  required  to  perform  these  tests  are  out- 
lined in  Appendices  B and  C.  The  tests  were  analyzed  as  presented  in 
Appendix  XII  of  Reference  2 . 
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The  A-7E  data  set  errors  were  as  follows: 

(a)  In  the  definition  of  composite  ALLCP,  the  control  point  name 
RADGYROE  was  misspelled  as  RADGYRDE,  leading  to  its  exclusion 
from  all  tests  involving  composite  ALLCP. 

I 

(b)  In  the  definition  of  composite  SEATPAN,  the  panel  name  SRSFWDUP 
was  shifted  left  one  column  out  of  its  data  field,  leading  to 
its  exclusion  from  tests  involving  composite  SEATPAN. 

* ' 

In  the  previously-used  MILSTAN  data  set,  the  GOMP  instruction  ABSVAL 
was  omitted  from  two  tests  where  absolute  value  of  test  results  was 
required.  This  occurred  in  the  MS33573  head  clearance  test  mentioned  above, 
and  also  in  the  MS33575  test,  "Rudder  pedals  neutral  adjustment,  neutral 
position  must  be  35.313  inches  from  NUTRLSRP".  Also,  the  instruction 
DIST  FWD  was  inadvertently  used  in  place  of  the  correct  form,  DIST  FORWARD, 
in  several  MS33574  tests.  In  the  GOMP  test  instruction  vocabulary, 
abbreviation  of  FORWARD  to  FWD  is  not  legitimate,  and  the  affected  tests 
were  cancelled. 

'f  v 

The  changes  to  GOMP  are  included  as  a set  of  UPDATE  directives  in  a 

card  deck.  This  deck  can  be  used  to  permanently  update  the  GOMP  program  using 

i- 

the  BCS  MAINSTREAM-EKS  version  of  the  CDC  6600  KRONOS  2.1  UPDATE  program. 

A listing  of  the  UPDATE  directives  is  included  along  with  the  augmented  A-7E 
and  revised  MILSTAN  data  sets  in  the  sample  execution  run  provided. 

The  recommendations  for  further  improvements  to  GOMP  are  in  the  remain- 
ing paragraphs  of  this  section.  The  GOMP  program  as  conceived  and  written 
has  a great  deal  of  potential  capability  which  has  never  been  activated.  The 

r IB  p 

recommendations  that  follow  are  in  the  nature  of  short-term  efforts  to  im- 
prove usage  and  efficiency. 
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These  recommendations  are: 


(a)  Improve  the  output  formats  to  make  MILSTAN  test  results  more 
readable. 

(b)  Remove  the  dependence  of  the  code  on  geometric  storage  size.  This 
requires  a reorganization  of  labelled  COMMON  storage  and  the 
recoding  of  a snlall  number  of  DIMEN SION -dependent  IF  statements 
in  FORTRAN. 

(c)  Provide  a package  of  dummy  subroutines  to  replace  certain  sub- 
routines whose  only  function  is  to  trace  program  flow  (and  print 
out  labelled  COMMON  storage  areas,  etc.)  for  purposes  of  checkout 

and  error  tracing.  Although  useful  when  needed,  roughly  2500o 

8 

central  memory  words  are  occupied  by  this  package.  An  original 
set  of  these  subroutines  can  be  kept  available  and  used  in  place 
of  the  dummies  when  needed. 

(d)  Roughly  7000g  words  of  storage  can  be  saved  by  decreasing  the 
buffer  size  for  the  files  INPUT,  OUTPUT,  TAPE10,  and  TAPE7  used 

by  GOMP.  This  requires  only  replacing  the  program  statement  card. 

(e)  Print  out  certain  informative  error  messages  which  are  currently 
printed  only  if  the  program  is  being  run  in  error-tracing  mode, 

as  described  in  (3).  Among  these  are  messages  which  would  provide 
detection  of  errors  in  coding  new  MILSTAN  test  instructions  as 
well  as  detection  of  geometry  data  errors. 
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3.0  COMPUTER  AIDED  DESIGN /CREWS TAT ION  GEOMETRY  EVALUATION  INTERFACE  MODULE 

Crewstation  geometry  descriptions  processed  by  CAD  are  not  compatible 
with  the  format  used  for  crewstation  geometry  descriptions  by  CGE.  The  CGE 
input  format  for  geometry  descriptions  is  much  more  cumbersome  to  use  than 
the  CAD  input  format.  This  is  due  to  the  fact  that  only  six  points  can  be 
used  to  describe  a geometric  item  in  CGE.  Because  of  this,  all  complex 
shapes  must  be  subdivided  into  several  component  parts  in  order  to  provide 
an  accurate  description  of  the  item.  The  CAD  Model,  on  the  other  hand,  does 
not  limit  the  number  of  points  that  can  be  used  to  describe  a geometric  item. 
It  was  decided  that  the  user  interface  with  CGE  could  be  greatly  simplified 
if  the  flexibility  of  data  input  inherent  in  the  CAD  Model  could  be  extended 
to  CGE. 

The  CAD/CGE  interface  was  developed  during  the  CAFES  Phase  V Program. 

The  interface  was  designed  to  provide  a means  of  formatting  CAD  output 
geometry  data  so  that  a crewstation  design  could  be  input  directly  to  the 
CGE  for  analysis  o reach  infeasibilities  or  to  test  for  compliance  with 
military  specifications  and  standards.  The  first  step  in  the  development 
of  this  interface  was  to  analyze  all  differences  between  the  CGE  and  CAD 
geometry  input  formats  to  determine  the  specific  conversions  that  would  be 
required  to  transform  CAD  output  data  into  CGE  input  data.  The  CAD/CGE 
interface  was  then  designed,  coded  and  integrated  into  CAFES.  A subset 
of  the  A-7E  cockpit  geometry  data  was  used  for  verification  of  the  new 
interface.  The  test  case  demonstrated  that  CGE  will  now  accept  crew- 
station geometry  data  in  the  output  format  provided  by  the  CAD/CGE 
interface.  The  following  section  contains  a general  description  of  the 
CAD/CGE  interface  module,  user  inputs,  model  outputs,  interface  module 
logic  and  formats  for  the  interface  data  bank  categories.  A CAD/CGE 
interface  module  sample  problem  is  contained  in  Appendix  D. 

3.1  General  Description 


The  purpose  of  this  module  is  to  retrieve  CAD  cockpit  geometry  data 
from  the  CAFES  data  bank,  convert  it  to  CGE  cockpit  geometry  format,  and 


output  it  in  card  deck  form.  The  output  geometry  data  will  be  in  design 
eye  reference  point  (DERP)  coordinates.  This  output  deck  may  then  be  used, 
in  the  same  manner  as  the  CDDATA  output  deck,  to  prepare  input  decks  for  the 
CGE  STORAGE,  CSPLOT,  and  GOMP  modules.  (See  Figure  6.) 

Figure  7 shows  the  data  flow  for  the  GAD/CGE  interface.  In  step  1,  the 
user  prepares  cockpit  geometry  data  in  CAD  format  and  inputs  it  to  the  CAFES 
(CAD)  data  bank.  The  required  cockpit  geometry  data  may  already  exist  in  the 
CAD  data  bank  as  a result  of  previous  work. 


In  step  2,  which  is  totally  separate  from  step  1,  the  user  prepares  a 
set  of  output  specification  cards  for  the  CAD/CGE  interface  module.  These 
cards  specify  the  geometric  items  and/or  subsystems  in  the  CAFES  data  bank 
which  will  be  output  as  cockpit  planes,  lines  and  control  points.  The 
output  specification  deck  also  names  a design  eye  reference  point  (DERP) 
and  specifies  whether  the  output  deck  will  be  in  the  STORAGE  or  GOMP  format 
If  STORAGE  format  is  specified  (step  2b,  Figure  7),  the  CAD/CGE  interface 
produces  a cockpit  plane  deck  and  control  point  deck  whose  coordinates  are 
in  the  DERP  coordinate  system.  These  two  decks  will  be  identical  in  format 
to  the  output  decks  produced  by  the  CGE  CDDATA  module.  If  the  GOMP  format 
is  specified  (step  2a,  Figure  7),  the  CAD/CGE  interface  produces  three 
decks  containing  points,  lines  and  planes  in  the  GOMP  format. 


3.2  User  Input  Specification 
3.2.1  CGE  Limitations  on  Geometry 

Geometric  input  data  for  all  modules  of  CGE  (except  GOMP)  is  limited 
to  bounded  planes  (maximum  of  six  vertices),  points  on  planes  and  points  in 
space.  GOMP  also  allows  the  input  of  lines  connecting  two  points  in  space. 

In  addition,  the  Boeman  Geometry  Evaluation  (BGE)  program  imposes  the 
following  requirements  on  input  geometry.  All  cockpit  planes  must  be  numbered 
and  planes  comprising  a three-dimensional  object  (such  as  the  pilot  seat) 
must  have  consecutive  plane  numbers.  Cockpit  controls  must  be  defined  as 
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points  on  a plane  or  points  in  space,  and  each  must  have  a unique  name  of 
up  to  10  characters  in  length.  GOMP  requires  that  all  geometric  objects  have 
8 character  names.  Standard  names  from  the  GOMP  dictionary  must  be  used  for 
geometric  objects  which  are  not  contained  in  a composite.  The  BGE  module 
requires  that  certain  reference  points  be  named  with  standard  names  (i.e., 
"NUTRLSRP"  for  neutral  seat  reference  point) . 

3.2.2  Limitations  on  CAD  Geometry 

Because  of  the  limitations  on  CGE  input  data,  the  user  of  the  CAD/CGE 
interface  will  be  constrained  in  the  matter  of  defining  crewstation  geometry 
via  the  CAD  model. 

3. 2.2.1  Naming  Convention 

When  defining  crewstation  geometry,  the  user  must  conform  to  the 
following  conventions. 

(a)  GOMP  Data  - All  cockpit  points,  lines  and  planes  which  will  be  part 
of  the  input  data  for  the  GOMP  module  must  be  named  using  the 
standard  GOMP  names  listed  in  the  CGE  user's  manual.  These  names 
are  all  8 characters  or  less  in  length. 

(b)  Other  CGE  Data  - Cockpit  planes  which  will  be  part  of  an  input  data 
set  to  a CGE  module  other  than  GOMP  may  have  names  up  to  30 
characters  in  length  providing  that  the  first  ten  non-blank 
characters  form  a unique  name  for  the  plane.  Cockpit  points  must 
have  unique  10  character  (o-r  less)  names.  Reference  points  defining 
the  seat  position  for  the  BGE  module  must  be  named  with  the 
standard  BGE  names  (NUTRLSRP,  SRPUP,  SRDOWN,  SRFORW,  SRPBACK) . 

3. 2. 2. 2 Defining  Cockpit  Objects 

When  defining  three-dimensional  cockpit  objects  such  as  a seat,  the  user 
must  define  a subsystem  exclusively  for  each  object  and  then  must  define  the 
object  as  a series  of  bounded  planes  belonging  to  that  subsystem.  As  an 
example,  a pilot  seat  might  be  defined  as  follows: 
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DEFINE  SUBSYSTEM  = S.1.1,  PILOT  SEAT/ 
SUBSYSTEM  = S.1.1/ 

DEFINE  ITEM  = BOUNDARY,  SEAT  BACK/ 


PLANAR 

DEFINITION 

= 7.5, 

112.75, 

274.97, 

7.5, 

99.15, 

270.6, 

-7.5, 

99.15, 

270.6/ 

2D  POINTS  = 0,  0, 

0,30 

30,30 

30,0/ 

DEFINE  ITEM 

= LINES,  SEAT  PAN/ 

PLANAR 

DEFINITION 

= 7.5, 

99.15, 

264.85, 

-7.5, 

99.15, 

264.85, 

-7.5, 

100.45, 

257.82/ 

2D  POINTS  = 0,0,  0,18.2,  18.2,  18.2,  18.2,0/ 

DEFINE  ITEM  = POINTS,  BACK  HEAD  REST/ 

POINTS  = 3.5,  134.53,  277.16, 

3.5,  125.7,  275.72, 

-3.5,  125.7,  275.52, 

-3.5,  134.53,  277.16/ 

As  shown  in  the  above  example,  cockpit  planes  may  be  defined  as 
geometric  items  of  the  type  "POINTS",  "LINES",  or  "BOUNDARY".  In  the 
case  of  a geometric  item  defined  by  3-D  points  such  as  the  "BACK  HEAD  REST" 
shown  above,  the  points  defining  the  item  must  all  be  co-planar. 

At  least  three  boundary  points  must  be  specified  for  each  cockpit 
plane.  There  is  no  limit  to  the  maximum  number  of  points  that  may  be 
specified,  as  long  as  the  polygon  formed  by  these  points  is  convex.  A 
cockpit  plane  whose  boundary  is  concave  may  not  have  more  than  six  points 
defining  the  boundary. 

Cockpit  planes  and  objects  to  be  accessed  by  the  CAD-CGE  interface  may 
not  contain  geometric  items  of  the  type,  CURVE,  CIRCLE,  CONIC,  ELIPSOID,  or 
POLYHEDRON. 
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3 .2. 2. 3 Defining  Cockpit  Lines 

The  user  may  define  cockpit  lines  foi  input  to  the  CGE  GOMP  module  by 
defining  them  as  geometric  items  of  the  type  "LINES".  The  user  must  define 
a subsystem  exclusively  for  the  cockpit  lines. 

As  an  example,  the  user  might  define  the  following  lines: 

DEFINE  SUBSYSTEM  = S.5.1,  GOMP  INPUT  LINES/ 

SUBSYSTEM  = S.5.1/ 

DEFINE  ITEM  = LINE,  ZAXIS/ 

POINTS  = 0,0,0,  0,0.1/ 

DEFINE  ITEM  = LINE,  DEPMCLRY/ 

POINTS  = 0,0,0,  -2.11,26.519,  -14,618/ 

DEFINE  ITEM  - LINE  VRAYFWD/ 

POINTS  = 0,0,0,  0,35.1,  -8.5/ 


3. 2. 2. 4 Defining  Panels  and  Controls 

The  user  may  define  panels  as  geometric  items  of  the  type  "PANEL"  with 
instruments  and  controls  defined  as  elements  on  the  panel.  As  with  other 
cockpit  objects,  the  user  should  define  a subsystem  exclusively  for  each  main 
panel  and  its  sub-panels. 

In  the  following  example,  a dummy  control  type  (consisting  only  of  a 
point)  is  defined: 

DEFINE  ELEMENT  = CONTROL,  POINT/ 

REFERENCE  POINT  =0,0/ 

Then  the  left  hand  console,  containing  three  panels,  is  defined: 

DEFINE  SUBSYSTEM  = S.3.2,  LEFT  HAND  CONSOLE/ 

SUBSYSTEM  = S.3.2/ 

DEFINE  ITEM  = PANEL,  FWD  LH  CONSOLE/ 
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PANE  COORDS  = -9.25,  102.03,  244.36, 

-18.75,  102.03,  244.36, 

-9.25,  105.09,  240.85/ 

BOUNDARY  = 0,0,  0,9,  2,9,  3,8,  3,0/ 

ELEMENT  - POINT,  F ILDGGRPOS / PLACEMENT  = 3.21,  3.7/ 
DEFINE  ITEM  = PANEL,  LH  CONSOLE/ 

PANEL  COORDS  = -9.25,  101.91,  244.5, 

-9.25,  101.91,  273.97, 

-19.96,  101.91,  244.5/ 

BOUNDARY  = 0,0,  0,29,  9,29,  9,0/ 

ELEMENT  = POINT,  AFCS  SWTCH/ PLACEMENT  = 7.55,  14.2/ 
ELEMENT  = POINT,  CNIADFCHAN/PLACEMENT  =2,2/ 

ELEMENT  = POINT,  CNIIFFMSTR/PLACEMENT  =9,  10.5/ 

ELEMENT  = POINT,  DATALNKCNT/ PLACEMENT  =5.7,  3/ 

DEFINE  ITEM  = PANEL,  AFT  LH  CONSOLE/ 

PANEL  COORDS  = -8.52,  101.91,  273.97, 

-8.52,  101.91,  279.15, 

-23.03,  101.91,  273.97/ 

BOUNDARY  = 0,0,  0,15,  6,15,  6,0/ 

ELEMENT  = POINT,  MSPSAGV/PLACEMENT  = 2.25,  13.5/ 


An  alternate  method  of  defining  panels  and  control  points  is  to 
define  the  panels  as  planes  and  define  the  control  points  as  points.  A 
geometric  item  of  the  type  POINTS  that  contains  only  one  point  is  assumed  by 
the  CAD-CGE  interface  module  to  be  a control  point. 


The  following  example  shows  how  this  method  would  be  used  to  define  the 
"AFT  LH  CONSOLE"  from  the  previous  example: 

DEFINE  ITEM  = BOUNDARY,  AFT  LH  CONSOLE 

PLANNAR  DEFINITION  = -8.52,  101.91,  273.97, 

-8.52,  101.91,  279.15, 

-23.03,  101.91,  273.97/ 

2D  POINTS  = 0,0,  0,15,  6,15,  6,0/ 

DEFINE  ITEM  = POINT,  MSPS  AGV/ 

POINT  = -10.77,  101.91,  276.22/ 


This  same  panel  could  also  be  defined  in  the  following  way: 

DEFINE  ITEM  = POINTS,  AFT  LH  CONSOLE/" 

POINTS  = -8.52,  101.91,  273.97, 

-8.52,  101.91,  279.15, 

-23.57,  101.91,  279.15, 

-23.03,  101.91,  273.97/ 

DEFINE  ITEM  = POINT,  MSPSAGV/ 

POINT  = -10.77,  101.91,  276.22/ 

The  control  point  "MSPSAVG"  in  the  previous  examples  would  not  have 
to  be  defined  with  the  panel,  but  instead  could  be  defined  in  a separate 
subsystem  with  all  the  other  controls. 

3. 2.2.5  Defining  Control  Points  and  Reference  Points 

The  user  may  define  cockpit  reference  points  and  control  points  as 
geometric  items  of  the  type  "RP"  or  the  type  "POINT".  A geometric  item  of 
the  type  "POINT"  or  "POINTS"  that  contains  only  one  point  is  assumed  (by 
the  CAD-CGE  interface)  to  be  a cockpit  control  point. 

Eye  reference  points  must  be  of  the  type  "RP"  and  must  define  a local 
coordinate  system  for  the  crewmember  such  that  the  Z axis  points  upward,  the 
Y axis  is  to  the  crewman's  left,  and  the  X axis  is  in  the  direction  of  his 
line  of  sight. 

The  following  example  illustrates  how  control  and  reference  points  may 
be  defined  for  the  CAD  data  bank.  Before  defining  any  points,  the  user 
must  define  a subsystem  exclusively  for  points  and  a subsystem  exclusively 
for  eye  reference  points: 

DEFINE  SUBSYSTEM  = S.4.I.,  CONTROL  POINTS/ 

DEFINE  SUBSYSTEM  = S.4.2,  EYE  REFERENCE  POINTS/ 
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Cockpit  control  points  and  reference  points  are  then  defined  for  these 
subsystems : 

SUBSYSTEM  = S.4.2/ 

DEFINE  ITEM  = RP,  PILOTS  ERP/ 

POINTS  = 41.7,  32.35,  42.33, 

41.12,  37.35,  42.33, 

41.7,  30.4,  42.33/ 

SUBSYSTEM  = S.4.1/ 

DEFINE  ITEM  = POINT,  NUTRLSRP/ 

POINT  = 41.7,  32.35,  7.13/ 

DEFINE  ITEM  = POINT,  SRP,  UP/ 

POINT  = 41.95,  32.35,  12.13/ 

DEFINE  ITEM  = POINT,  SRP,  DOWN/ 

POINT  = 41.5,  32.35,  2/ 

DEFINE  ITEM  = POINT,  MSPSAVG/ 

POINT  = -10.77,  101.91,  276.22/ 

3.3  User  Output  Specification 

It  is  via  the  output  specification  commands  that  the  user  directs 
the  actions  of  the  CAD-CGE  interface.  The  user  will  implement  execution 
of  the  interfaces  as  follows: 

BEGIN  CGE  INTERFACE/ 

PUNCH  = CAD  DATA/ 

The  user  will  specify  which  CGE  module  the  output  data  deck  is  destined 
for  by  issuing  one  of  these  commands: 

STORAGE/  or  GOMP/ 

With  the  same  command  he  may  specify  that  the  deck  be  printed  as  well 
ns  punched  by  including  the  optional  operand  "LIST".  Example: 

STORAGE  = LIST/  or  GOMP  = LIST/ 
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The  user  must  then  specify  an  eye  reference  point  as  follows: 


ERP  = name/ 

where  "name"  is  the  name  of  the  eye  reference  point.  As  required  by  the 
CGE  modules  GOMP  and  BGE,  the  coordinates  of  the  output  data  will  be 
converted  to  the  coordinate  system  of  the  associated  eye  reference  point. 

An  optional  command  may  be  inserted  at  this  point  to  specify  the  cockpit 
code  and  cockpit  description: 

COCKPIT  DESCRIPTION  = XXX,  description/ 

where  "XXX”  is  a three -character  cockpit  code  and  "description"  is  a 50- 
character  description  of  the  cockpit. 

After  specifying  the  eye  reference  point,  the  user  must  specify  the 
geometry  to  be  included  in  the  output  data  deck.  He  specifies  this  with 
one  or  more  of  the  following  type  commands: 

SUBSYSTEM  = ddn^  ....  ddn  / 

When  each  "ddn"  is  a subsystem  Dewey  decimal  number.  From  one  to  twenty 
subsystems  may  be  specified  in  each  command. 

The  output  specification  for  a data  deck  is  ended  by  any  other  command 
such  as  another  "PUNCH  = " command  or  an  "END  CGE  INTERFACE/"  command. 

3.4  The  CAD/CGE  Interface  Logic 

The  CAD-CGE  interface  consists  of  one  subroutine  within  the  CGE  inter- 
face module.  The  subroutine  is  named  CGCAD.  It  is  called  by  the  main 
routine  CCCGE  upon  encountering  the  command  "PUNCH=CAD  DATA/".  It  then 
reads  subsequent  commands  in  the  following  order  and  takes  the  following 
actions . 
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CGCAD  will  read  one  of  the  following  four  commands  and  set  switches 
as  follows: 


COMMAND 

STORAGE/ 

STORAGE  = LIST/ 
GOMP/ 

GOMP  = LIST/ 


GOMP  SWITCH 

cleared 

cleared 

set 

set 


LIST  SWITCH 

cleared 

set 

cleared 

set 


The  next  command  must  be  of  the  type  "ERP  = name".  CGCAD  will  call  CALTMX 
to  setup  a transformation  matrix  to  transform  points  from  the  primary 
coordinate  system  into  the  ERP  coordinates. 

An  operational  command,  COCKPIT  DESCRIPTION  = code,  description/,  may 
be  entered  at  this  point.  The  "description"  may  be  up  to  50  characters 
in  length  and  will  be  inserted  in  the  descriptor  cards  for  the  COCKPITXXX 
and  CONTROLXXX  data  deck  to  be  punched  by  CGCAD.  The  cockpit  "code"  must  be 
three  alphanumeric  characters  and  will  be  substituted  for  XXX  in  the 
COCKPITXXX,  CONTROLXXX  and  CONSHAPXXX  table  names.  If  this  command  is  not 
entered,  the  cockpit  description  in  the  descriptor  cards  will  be  blank. 


The  next  commands  must  be  of  the  type  "SUBSYSTEM  = ddn^,  ...,  ddn^Q/". 
Any  number  of  this  type  command  may  be  specified  and  each  command  may 
specify  from  one  to  twenty  subsystems. 


CGCAD  will  process  the  subsystems  one  at  a time.  For  each  subsystem, 
a list  of  the  geometric  items  in  the  subsystem  will  be  built.  Each 
geometric  item  will  then  be  processed  according  to  their  type  and  the 
number  of  points  they  contain.  Polyhedrons  and  3-D  surfaces  will  not  be 
processed.  All  other  geometric  items  will  be  treated  as  control  or  reference 
points  if  they  contain  one  point  or  are  of  the  type  "RP"  (reference  point), 
lines  if  they  have  two  points,  and  planes  if  they  have  three  or  more  points. 
Geometric  items  defining  lines  will  be  processed  only  if  the  GOMP  switch  is 
set . 
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When  processing  the  subsystems  and  their  geometric  items,  CGCAD  will 
do  the  following: 

(a)  Number  each  cockpit  plane  consecutively  starting  with  1. 

(b)  If  the  GOMP  switch  is  not  set  for  each  subsystem  that  contains 
planes,  generate  a category  100  record  where  parameter  1 is  the 
subsystem  name,  parameter  2 is  the  number  of  the  first  plane  in 
the  subsystem,  and  parameter  3 is  the  number  of  the  last  plane 
in  the  subsystem.  (See  Table  1 for  category  descriptions) 

(c)  For  each  geometric  item  that  describes  a plane,  generate  a category 
104  record.  If  the  plane  is  defined  by  more  than  six  verticies, 
split  it  into  two  or  more  adjacent  planes  of  six  or  less  verticies. 

(d)  For  each  geometric  item  that  describes  a point,  generate  a 
category  102  record. 

(e)  If  the  GOMP  switch  is  set,  for  each  geometric  item  that  describes 
a line,  generate  a category  103  record. 

(f)  For  each  geometric  item  that  describes  a control  panel  (type 
"PANEL")  generate  a category  104  record  for  the  panel  plane  and 

a category  102  record  for  each  control  or  instrument  on  the  panel. 

When  all  subsystems  have  been  processed,  CGCAD  will  then  produce  the 
specified  output  deck.  For  GOMP,  the  records  in  categories  102,  103  and  104 
will  be  processed  in  that  order  to  produce  the  GOMP  data  deck.  For  STORAGE, 
the  records  in  categories  104,  102  and  100  will  be  processed  in  that  order 
to  produce  the  STORAGE  data  deck. 

3.5  Data  Bank  Category  Formats 

The  formats  for  the  data  bank  categories  100,  102,  103  and  104  used  by 
CGCAD  are  shown  in  the  following  tables. 
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Category  Type: Secondary 
Category  Number : 100 

Category  Name:  Cockpit  Shapes 


Word 


Parameter 

Number 


Variable 

Name 


Parameter  Name 


Parameter 

Type 


Number  of 
Words  or 
Characters 


Secondary 

Category 

Usage 


1-3 


’ 2 


Eockplt  Shape  Name  - 
p to  30  characters 


Hollerith 


Plane  number  - lower  boupd  Integer 
p’lane  number  - upper  bouhd  Integer 


30 


Table  1.  Format  for  CGCAD  Data  Bank  Categories 


Category  Type; Secondary 
Category  Number:  102 

Category  Name:  Cockpit  Points 


Parameter 

Number 


Variable  ; 
Name 


Parameter  Kama 


Parameter 

Type 


Number  of 
Words  or 
Charactera 


Control  Point  Name: 
30KP  - up  to  8 charac- 
ters, BCE  - up  to  10 
:haractera  In  length 


Control  Point  Coordinate 
Y,  Z 


Plane  numbers  that  con-  . 
trol  point  13  imbedded 
in.  Set  to  -0  if  not  on 
a plane 


Table  1.  Format  for  CGCAD  Data  Bank  Categories  (cont.) 


/ 

Table  1.  Format  for  CGCAD  Data  Bank  Categories  (cont.) 
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Category  Type;  secondary 

Category  Humber:  104 

Category  Name:  Cockpit  Planes 

Word 

Parameter 

Number 

Variable 

Name 

Parameter  Name 

Parameter 

Type 

Number  of 
Words  or 
Characters 

Secondary 

Category 

Usage 

l 

1 

Plane  Number 

Hollerith 

10 

2-4 

2 

Description  of  Plane  - 
Up  to  30  characters 
long 

Hollerith 

30 

5 

3 

Number  of  Vertices  (n) 

Interger 

1 

6-23 

4 

Vertices  of  Plane  in 
form: 

V V 2i 

X , Y , Z 
n n n 

Real 

18 

24 

5 

Plane  Name  - used  only 
for  COMP 

tollerith 

10 

Table  1.  Format  for  CGCAD  Data  Bank  Categories  (cont.) 
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4.0  REVIEW  OF  THE  CGE  REACH  BASKET  ANALYSIS  COMPUTER  PROGRAM 


A Reach  Basket  Model  was  developed  during  the  CGE  Program  to  provide 
reach  envelopes  for  crewmen  of  various  sizes.  The  Reach  Basket  Model  was 
not  completed  before  the  end  of  the  CGE  Program.  This  was  unfortunate, 
since  the  reach  analysis  program  of  the  CAD  Model  requires  reach  envelope 
data.  Completion  of  the  Reach  Basket  Model  would  provide  a means  to 
automatically  generate  the  reach  envelope  data  required  by  CAD. 

The  CGE  Reach  Basket  Model  was  examined  during  the  CAFES  Phase  V 
Program  to  obtain  an  estimate  of  the  resources  that  would  be  required  to 
complete  and  update  the  model.  The  original  design  objectives  of  the 
Reach  Basket  Model  were  reviewed  and  evaluated  with  respect  to  the  CAD 
reach  analysis  input  requirements  and  the  anticipated  demand  for  reach 
envelope  data  for  crewmen  of  various  sizes  and  different  seat  positions 
within  the  cockpit.  Particular  emphasis  was  placed  upon  efficiency 
improvements  and  enhancing  the  user  interface.  It  was  concluded  that  a 
significant  reduction  could  be  achieved  in  both  the  amount  of  core  memory 
and  the  execution  time  of  the  Reach  Basket  Model  by  modifying  the  current 
optimization  routine.  It  was  also  concluded  that  the  amount  of  effort 
required  in  terms  of  manpower  and  computing  requirements  to  complete  the 
improved  optimization  model  would  be  justified  by  a significant  reduction 
in  the  cost  of  running  the  Reach  Basket  Model. 

A discussion  of  the  possible  refinements  to  the  Reach  Basket  Model  is 
contained  in  the  following  section.  Also  included  in  this  section  is  a new 
set  of  documentation  for  all  ot  the  programs  that  are  stored  in  the  Man 
Model  Library.  The  library  contains  nine  main  programs  and  92  subprograms 
that  were  used  to  build  several  different  versions  of  BOEMAN. 

4.1  The  CGE  Reach  Basket  Analysis  Computer  Program 

4.1.1  Background 

The  CGE  Reach  Basket  Analysis  (RBA)  computer  program  was  conceived 
during  the  Phase  III  CGE  effort  as  an  add-on  item.  It  was  felt  desirable 
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to  have  a motion-model  program  similar  to  the  BOEMAN  man-model  (the  BGE 
model),  but  adapted  to  finding  reach  limits  as  opposed  to  simulating  motions 
in  a task-oriented  fashion.  A link-system  model  using  a simple  vector 
geometry  approach  has  been  proposed  for  an  RBA  model.  In  this  approach, 
the  links  are  connected  with  2 degrees  of  freedom  so  that  total  distance 
from  the  base  of  the  link  system  to  a reach  point  can  be  calculated. 

However,  this  method  neglects  the  effects  of  angular  limits  in  the 
joints  of  the  human  link  system.  Some  of  these  joints,  such  as  the 
shoulder,  have  3 degrees  of  freedom,  as  in  a universal  joint.  The  upper 
arm  has  not  only  a bend  angle  9 (relative  to  some  reference  bend)  in  a 
bend  direction  <j>  (again,  relative  to  some  reference  orientation),  but  has 
also  a torsion  or  twist  angle  \p.  Neglecting  to  model  all  degrees  of 
freedom  with  their  accompanying  excursion  limits  might  yield  an  inaccurate 
assessment  of  human  reach  capability. 

Another  disadvantage  of  simple  vector  geometry  models  is  that  link 
placements  must  somehow  be  calculated.  This  is  not  seen  to  be  a trivial 
problem,  especially  if  spine  placement  is  to  be  included  in  the  link- 
system  model.  An  ad  hoc  or  "heuristic"  method  for  link  placements  would 
appear  to  be  risky.  The  placement  of  a link  close  to  the  base  of  the 
link-system  (e.g. , close  to  the  top  or  the  bottom  of  the  spine)  can  have 
a very  great  effect  on  links  close  to  the  end  of  the  system  (i.e.  , the 
hand  or  fingertip  point).  Taking  account  of  these  effects  to  avoid  an 
unstable  or  a highly  inaccurate  reach  calculation  could  be  complicated. 

The  CGE  motion  model  used  in  the  BGE  computer  program  avoids  both 
pitfalls.  It  is  structured  with  all  degrees  of  freedom  in  the  link- 
connecting joints,  and  it  incorporates  an  iterative  method  for  solving 
nonlinear  constrained  minimization  problems  to  calculate  the  link 
placements.  Angular  limits  are  readily  imposed  in  the  link-system  model  , 
and  the  link  placement/orientation  angles  themselves  (Euler  angles)  are 
calculated  using  a general  nonlinear  equation  solution  method  to  force 
the  link  system  to  reach  for  a point  in  space  or  orient  itself  in  some  way. 
The  solution  process  is  iterative  and  allows  total  freedom  of  all  joint 


angles  to  be  varied  simultaneously  to  find  a solution.  Stability  and  solu- 
tion accuracy  are  controlled  by  fixing  certain  parameters  in  the  model  to 
adapt  the  solution  technique,  which  uses  known  optimization  methods,  to  the 
link-system. 

4.1.2  Source  of  the  Model 

The  Reach  Basket  Analysis  model  in  its  present  form  is  simply  one  of 
the  possible  configurations  from  the  Man-Model  Development  Library  (MMDLIB) 
system  (Reference  4) . Some  of  the  MMDLIB  subroutines  exist  in  a version 
specifically  adapted  to  reach  analysis  (RBA  version).  Others  are  taken 
straight  from  the  CGE  Phase  II  motion  model  (MAN2) , which  solves  for  spine 
position  concurrently  with  arm  position.  The  CGE  Phase  III  motion  model 
(MAN3)  has  separate  body  systems,  and  for  simplicity  it  was  decided  to  use 
MAN2  for  the  Reach  Basket  Analysis  version.  Since  only  a one-arm  model  is 
used,  MAN2  is  nearly  as  efficient  for  this  purpose  as  MAN3. 

The  present  RBA  model  was  originally  developed  to  "prove  the  concept", 
and  is  not  "streamlined"  as  a finished  product.  Much  unneeded  code  appli- 
cable only  to  the  BGE  motion  model  remains,  even  in  the  RBA  versions  of  the 
specifically  adapted  subroutines.  The  Input/Output  and  environmental  inter- 
face subroutines,  EVALO,  INJECT,  and  RTTE,  can  be  changed  to  greatly  improve 
usage.  The  optimization  code  can  be  replaced  by  more  efficient,  up-to-date 
codes.  Also,  the  reach  analysis  optimization  package  can  possibly  be 
reformulated  to  improve  efficiency. 

4.1.3  The  Link-System  Tree  Structure 

In  its  most  general  form,  the  motion-model  link-system  is  a tree  with 
6 branches  (Figure  8) . The  origin  (both  for  3-space  Cartesian  coordinates 
and  for  the  tree  network)  is  the  bottom  of  the  spine.  From  this  point,  three 
branches  emanate.  These  are  the  spine,  left  leg,  and  right  leg  systems.  The 
spine  system  ends  at  the  tip  of  the  spine,  and  from  there  emanate  three  fur- 
ther branches,  the  head,  left  arm,  and  right  arm  systems.  They  are  joined 
together  in  the  motion  model  code  by  subsequent  calls  to  subroutine  TRANSF. 


Figure  8.  Link-System  Tree  Structure 


Subroutine  TRANSF  calculates  rotation  matrices  from  Euler  angles  and  also 
returns  joint  locations  for  one  body  system  when  it  is  called. 

For  the  BGE  model,  all  six  body  systems  are  used.  Most  of  the  code  for 
this  remains  in  the  RBA  model,  yet  only  the  spine  and  one  arm,  possibly  with 
a simplified  head  system  and  a leg  system,  are  needed. 

Also,  the  specific  structure  being  used  is  input  to  the  motion  model 
through  subroutine  INJECT  (unless  it  is  being  used  as  an  overlay  in  the  BGE 
environment).  Not  only  link  lengths,  but  angular  limits  and  even  the  link 
structure  itself  (such  as  the  degrees  of  freedom  in  each  link  and  how  many 
links  are  in  each  body  system)  are  input.  In  a fixed  RBA  model,  this 
detailed  input  could  be  eliminated  and  the  link  system  structure  could  be 
set  in  DATA  statements. 

4.1.4  Sequencing  Logic 

Subroutine  TASK1,  the  motion-model  sequencing  logic,  controls  execution 
of  task  motions.  It  is  the  motion  model's  brain  (the  optimization  package, 
which  actually  performs  the  task  motions,  can  be  thought  of  as  the  neuro- 
muscular system).  This  logic  is  oriented  toward  BGE  task  motions  and  in  the 
present  RBA  model  is  overridden  by  the  RBA  version  of  the  environmental  sub- 
routine, EVALO.  It  is  not  completely  overridden,  but  the  effect  of  having 
EVALO  cancel  out  some  of  the  task  logic  is  a storage  inefficiency.  Stream- 
lined versions  of  these  two  subroutines  would  eliminate  this. 

4.1.5  Optimization  Improvements 

The  optimization  package  can  be  replaced  with  an  approximately  equiva- 
lent capability  to  save  10,000  octal  central  memory  words  on  the  CDC  6600. 
Some  performance  improvements  and  computer  time  reductions  could  be  achieved 
with  the  improved  package,  but  these  are  hard  to  estimate  as  of  this  writing. 
A small  additional  effort  would  provide  this  improvement,  since  some  work 
has  already  been  done  for  this  report.  A certain  amount  of  work  remains 
to  maximize  the  efficiency  of  the  improved  optimization  package  in  the 
mot  if. n model.  Optimization  improvements  could  be  incorporated  in  the 
BGE  model. 
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4.1.6  Coding  Improvements 

Triply-dimensioned  arrays  in  a nested  iterative  loop  procedure  are 

\ v 

presently  used.  An  improved  optimization  procedure  can  reduce  the  number 
of  iterations  and  thus,  reduce  the  time  required.  However,  significant 
timing  reductions  can  also  be  achieved  by  speeding  up  calculations  inside 
the  iteration  loops.  Elimination  of  triply-dimensioned  arrays  and  the 
substitution  of  singly-dimensioned  arrays  should  be  done  to  speed  up  the 
calculations  involving  those  arrays  affected. 

Recoding  some  of  the  labelled  COMMON  storage  can  greatly  reduce  unused 
space.  The  Reach  Basket  Analysis  model  retains  the  storage  scheme  of  the 
original  Boeman  Geometry  Evaluation  labelled  COMMON  it  inherits.  This 
provides  for  storage  of  36  link-system  connecting  points  (3  coordinates 
each)  and  36  rotation  matrices  (3  x 3)  and  their  derivatives.  In  the  RBA, 
half  of  these  points  would  be  needed  at  most,  and  probably  fewer.  In  any 
case,  storage  for  points  and  rotations  can  be  cut  in  half  by  recoding  3 
labelled  COMMON  statements  that  appear  in  11  subroutines  and  recoding 
statements  that  use  the  affected  arrays. 

If  all  improvements  are  made,  a compact,  "fixed"  Reach  Basket  Analysis 
model  will  be  available.  Additional  work  could  enhance  performance,  but  the 
changes  mentioned  in  this  report  can  be  implemented  more  economically  and 
will  greatly  reduce  the  cost  of  running  the  RBA  computer  program. 

Timing  reduction  improvements  are  hard  to  forecast  as  of  this  writing, 
hence  they  are  not  specified  in  the  following.  However,  improvements  in 
both  computer  time  and  performance  will  result  from  the  changes  mentioned. 

It  should  be  possible  to  reduce  computer  run  time  of  the  model  by  50%  or 
more.  Estimated  storage  reductions  for  each  of  the  proposed  Reach  Basket 
Analysis  improvements  are  shown  in  Table  5. 
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STORAGE 
REDUCTION 

IMPROVEMENT (OCTAL) 

1.  Fixed  link-system  tree  (reduce 
input) . 

2.  Recode  TASK1,  EVALO  and  I/O 
including  buffer  size  (reduce 
storage,  improve  usage). 

3.  Optimization  (reduce  storage,  100C0 

cut  timing,  improve  performance) . 

4.  Labelled  COMMON  (reduce  storage,  5700 

cut  timing) . 

TOTALS  20600 

Table  2.  Storage  Reductions  for  RBA  Improvements 

The  implementation  of  these  changes  could  be  done  in  a stepwise  manner, 
with  check  points  along  the  way.  If  it  becomes  obvious  at  some  point  that 
computer  run  time  reductions  are  not  of  the  order  of  50%  or  greater,  develop- 
ment could  be  limited  to  achieving  storage  reductions  by  recoding  portions 
other  than  optimization.  User  improvements,  i.e.,  simpler  input  and  reformat- 
ted output,  are  implicit  in  this  recoding. 

4.1.7  Usage  of  the  Current  Model 

The  current  model  is  set  up  to  analyze  reach  extent  for  a one-arm  model 
with  varying  degrees  of  spine  motion  (including  none).  Spine  and  clavicle 
restra:nts,  such  as  seat  belts  and  shoulder  straps,  are  simulated  by  narrow- 
ing the  range  of  freedom  in  the  angular  limits  for  spine  and/or  clavicle 
angles.  Any  link  or  set  of  links  can  be  "frozen"  by  specifying  no  degrees 
of  freedom.  Thus,  for  the  spine,  the  IQ  array  (which  specifies  the  links  to 
which  variable  Euler  angles  belong)  will  omit  all  spine  link  indices  if  the 
spine  is  to  be  fixed  for  a reach  analysis. 
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The  reach  analysis  is  performed  by  specifying  the  elevations  of  a set 
of  horizontal  planes  and  rays  at  various  azimuth  angle  values  on  the  planes. 

The  rays  emanate  from  the  Z-axis  of  the  bottom-of-spine  reference  system, 
which  is  the  motion-model  origin.  In  this  system  the  Z axis  points  straight 
up;  X is  to  the  right,  and  Y is  forward  in  the  work  station  space  of  the 
simulated  human  operator.  An  annotated  listing  of  the  input  variables  for 
the  Reach  Basket  Model  are  contained  in  Appendix  E. 

4.2  The  CGE  Man-Model  Development  Library  (MMDLIB) 

During  development  of  the  man  model  (in  this  discussion  "man  model"  and 
"motion  model"  will  be  used  interchangeably)  for  the  Cockpit  Geometry  Evalu- 
ation Computer  Program  System  (CGECPS),  a library  of  related  programs  and 
subroutines  came  into  being.  This  was  a result  of  the  different  avenues  of 
approach  to  modeling  which  were  tried,  as  well  as  year-to-year  refinements 
and  development  of  ancillary  programs  for  processing  data  on  human  subject  mo- 
tions both  for  research  and  for  statistical  validation  of  the  computer  model. 
There  are  currently  9 main  programs  and  92  subroutines  stored  on  tape  in  dif- 
ferent versions  as  separate  UPDATE  decks  in  a MAINSTREAM- EKS  UPDATE  program 
library  file.  An  annotated  listing  of  these  programs  and  subroutines  is  con- 
tained in  Appendix  F. 

Many  of  the  UPDATE  subroutine  decks  are  different  versions  of  certain 
subroutines  which  are  used  in  alternate  versions  of  the  CGE  motion  model. 

These  different  versions  reflect  the  year-to-year  stepwise  development  effort 
for  and  different  applications  of  the  motion  model.  Initially,  for  example, 
the  motion  model  had  only  fixed  lower/upper  bounds  on  the  Euler  angle  param- 
eters which  vary  to  move  the  link  system.  In  subsequent  years,  variable  bounds 
were  introduced  for  certain  Euler  angles. 

In  fact,  two  different  strategies  were  tried  for  varying  these  bounds, 
and  two  different  versions  of  the  variable-angular-limits  model  are  avail- 
able as  a result.  The  two  strategies  have  resulted  in  (a)  the  Variable 
Joint  Angular  Limits  model  (VJAL)  and  (b)  the  Discrete  Variable  Joint 
Angular  Limits  model  (DVJAL) . In  VJAL,  the  limits  are  varied  continuously 
during  the  calculation  of  a link-system  position  (using  the  optimization 
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procedure  in  LYNX).  Recall  that  a sequence  of  positions  makes  up  a man- 
model  task  motion.  In  DVJAL,  the  varying  angular  limits  are  fixed  during 
the  calculation  of  a link-system  position,  and  are  then  adjusted  prior  to 
the  next  position  calculation  to  "catch  up"  with  the  changed  link-system 
configuration.  Hence,  in  DVJAL  the  limits  are  varied  in  a discrete,  as 
opposed  to  continuous,  fashion.  The  discrete  model  runs  faster  on  the  com- 
puter, although  the  continuous  model  gives  more  accuracy  in  satisfying  the 
limits . 

Another  version  of  the  motion  model  resulted  from  the  need  for  special 
statistical  validation  runs.  In  these  runs  the  computer  model  (the  VAL  ver- 
sion) was  required  to  perform  a task  sequence  and  then  output  the  data  in  a 
special  format  for  a statistical  validation  program. 

The  Reach  Basket  Analysis  program  is  yet  another  version.  Here,  the 
Phase  II  main  program,  MAN2,  is  used  in  conjunction  with  the  motion  model 
subroutine  package  with  some  subroutines  deleted  and  others  supplied  in  a 
version  (the  RBA  version)  specifically  adapted  to  reach  basket  analysis. 

For  example,  the  link-system  for  reach  basket  analysis  (RBA)  contains  only 
the  spine  and  one  arm.  Also,  a reach  envelope  task  motion  consists  of  only 
one  position,  and  the  task  requirement  is  to  reach  as  far  as  possible  along 
a specified  reach  ray  (instead  of  touching  a control  point).  Hence,  the  task 
specification/link  system  sequencing  logic  (subroutine  TASK1)  and  programming 
environment  interface  (subroutine  EVALO)  are  different  for  the  RBA  than  for 
any  of  the  other  versions. 

At  this  point,  it  might  be  helpful  to  briefly  describe  the  general  struc- 
tural philosophy  of  the  motion  model  as  a computer  program  package.  There  are 
five  main  elements  in  all  of  the  versions  of  the  motion  model  computer  program 
package  (e.g.  the  RBA  version).  These  are  (Figure  9): 

(I.  The  main  program,  MAN2  or  MAN3,  depending  on  whether  a Phase  IT  or 
Phase  III  type  model  is  to  be  used  (Phase  III  has  separate  opti- 
mizations for  the  major  body  systems,  right  arm,  left  arm,  head, 
etc. ) . 
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Figure  9.  Basic  Motion  Model  Structure 


(2)  The  optimization  main  subroutine  (presently  LYNX),  which  minimizes 
an  "effort"  function  while  requiring  the  man-model's  hands  (or 
feet)  to  reach  certain  controls  or  the  eye  to  view  a control.  The 
result  of  this  iterative  constrained  minimization  process  is  a 
vector  of  Euler  angles  for  the  link-system  joints.  This  prescribes 
one  position  in  the  motion  sequence  for  one  task. 

(3)  The  control  logic  (subroutine  TASK1) , which  performs  all  calcula- 
tions not  done  by  the  optimization  package.  For  example,  the  input 
control  points  for  a task  are  used  together  with  the  initial  hand 
(or  feet)  positions  and  a preset  step  length  to  calculate  a sequence 
of  intermediate  control  points  (Figure  10) . The  optimization 
package  then  uses  the  intermediate  control  points  as  constraints 

on  the  hand  (feet)  positions  when  calculating  the  Euler  angles 
for  one  positions  of  a task  motion. 

(4)  Any  interface  logic  required  to  perform  I/O  or  needed  specialized 
calculations  to  interface  the  motion  model  with  its  programming 
environment.  This  component  is  subroutine  EVALO,  which  like  TASK1 

has  many  entry  points  (EVALxx) . The  calls  to  these  entry  points 
are  distributed  throughout  the  MAN2  or  MAN3  code  in  like  fashion 
to  the  TASKxx  calls.  Whereas  TASK1  contains  logic  entirely  related 
to  the  motion  model  task  sequencing,  EVALO  can  be  programmed  as 
desired  to  pass  information  to  and  from  the  motion  model  and  the 
user.  The  entry  points  EVALxx  can  even  be  used  to  modify  the  task 
sequencing,  overriding  TASKxx  in  the  process. 

(5)  The  lower-level  subroutines  called  by  components  (1)  through  (4) 
to  perform  the  calculations. 

An  example  of  a specific  motion  model  package  corresponding  to  that  in 
Figure  9 is  the  detailed  sketch  of  the  RBA  version  shown  in  Figures  11  and 
12.  Each  subroutine  is  shown  as  a box  with  a name,  followed  by  the  deck 
name  in  parentheses.  The  deck  name  is  that  of  the  MMDLIB  version  of  the 
subroutine  being  used  (many  subroutines  have  more  than  one  version,  with 
different  deck  names).  The  main  program  is  MAN2,  but  with  the  PROGRAM  state- 
ment card  located  in  deck  MAN2PRG.  Hence,  the  two  UPDATE  decks  MAN2PRG  and 
MAN2  are  reeded  for  the  RBA  version  of  program  MAN2. 
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Figure  10.  Spine  Riglit  Arm  System  at  Position  3 
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Figure  12.  RBA  Structure  - Levels  4,  5 and  6 
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For  RBA,  input  from  cards  is  required  to  specify  reach  analysis  param- 
eters (e.g.,  the  number  of  horizontal  reach  planes,  the  number  of  horizontal 
reach  rays  in  each  plane,  and  the  spacing  of  the  planes  along  the  vertical 
Z axis).  Hence,  interface  subroutine  EVALO,  in  its  RBA  version  (deck 
EVALRBA) , calls  input  subroutine  INJECT.  Since  INJECT  is  a general  purpose 
man-model  input  routine  which  contains  a call  to  B0DX  (input  solid  body 
segments  to  be  positioned  along  with  the  link-system  links) , a dummy  version 
of  subroutine  B0DX  (deck  B0DNULL)  is  supplied  to  save  time  and  storage  in 
the  computer.  After  all,  the  RBA  model  has  no  need  for  body  segment  solids. 


5.0  DATA  MANAGEMENT  SYSTEM/ CREWSTATION  GEOMETRY  EVALUATION  INTERFACE  MODULE 


The  DMS/CGE  interface  module  was  developed  in  Phase  V of  the  CAFES  Program 
to  allow  the  CGE  user  to  employ  DMS  capabilities  for  inputting  much  of  the 
CGE  data.  To  complete  this  interface,  a set  of  primary  and  secondary  data 
categories  were  established  to  receive  input  data  required  by  each  of  the 
CGE  computing  functions  (crewstation  geometry  description,  BOEMAN,  Reach 
Basket  Analysis,  GOMP,  etc.).  The  CGE  data  handled  by  the  DMS  includes  cock- 
pit plane  and  control  definitions,  control  shape  data,  and  task  sequence 
data.  The  execution  and  report  commands  of  CGE  were  incorporated  under 
the  CAFES  executive.  Then,  a set  of  data  for  the  A-7E  was  input  to  the 
DMS  to  demonstrate  CGE  model  input,  execution  and  output  via  the  CAFES 
DMS.  The  test  case  demonstrated  that  the  DMS  will  accept  all  of  the  CGE 
data  categories  as  inputs  and  output  that  data  on  cards  in  a format 
compatible  with  the  CGE  input  requirements.  A description  of  the  user  in- 
puts, model  outputs,  interface  logic,  and  formats  for  the  interface  data 
bank  categories  is  contained  in  tne  following  section.  A DMS/CGE  interface 
module  sample  problem  is  contained  in  Appendix  G. 

5.1  General  Description 

The  purpose  of  this  module  is  to  allow  the  CAFES  user  to  input  certain 
CGE  data  (cockpit  plane  and  control  definition  and  task  sequence  data) 
to  CAFES  in  a free  field  format,  store  this  data  in  the  CAFES  data  bank, 
and  at  user  command,  retrieve  the  data  and  output  it  in  card  deck  form 
in  CGE  format.  The  output  deck  containing  the  cockpit  plane  and  control 
definitions  will  have  a format  identical  to  the  CGE  CDDATA  input  deck. 

The  task  sequence  output  deck  will  have  a format  identical  to  the  task 
sequence  input  deck  for  the  CGE  STORAGE  module. 

Figure  13  shows  the  data  flow  for  the  DMS/CGE  interface.  In  step  1, 
the  user  prepares  cockpit  geometry  and  task  sequence  data  in  the  CAFES 
free  field  format  and  inputs  it  to  the  CAFES  (CGE  interface)  EDITOR  which 
stores  it  in  the  CAFES  (CGE  interface)  data  bank. 
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In  step  2,  which  is  totally  separate  from  step  1,  the  user  prepares  a 
set  of  output  requests  for  the  DMS/CGE  interface  module.  These  requests 
specify  which  CGE  data  to  retrieve  from  the  CAFES  (CGE)  data  bank.  Following 
the  user  output  requests,  the  DMS/CGE  interface  module  retrieves  the 
specified  data,  structures  it  into  the  CGE  format,  and  outputs  it  in  card 
deck  form. 

5.2  User  Input  Specification 


CGE 

input  data  consists 

of  five  parts: 

1) 

cockpit  planes  data, 

2) 

controls  data. 

3) 

eye  reference  points 

data. 

4) 

task  sequence  data. 

and 

5) 

control  shapes  data. 

The  user  will  initiate  the  input  of  this  data  while  in  the  CAFES  EDITOR 
with  the  command 

BEGIN  CGE  INPUT  = (3  character  crewstation  code) 
and  end  the  input  of  this  data  with  the  command 
END  CGE  INPUT  / . 

The  five  major  sections  of  the  CGE  data  will  be  input  using  the  following 
commands . 

5.2.1  Cockpit  Planes  Data 

The  user  will  utilize  the  command 

COCKPIT  PLANES  = (160  character  descriptor)  / 
to  tell  the  program  that  the  cockpit  plane  definitions  are  to  follow. 
After  this  command  is  executed,  the  user  then  inputs  each  cockpit  plane 
using  the  following  commands. 

NAME  = (30  character  name)  / 

NUMBER  = (value)  / 

VERTICES  = (maximum  of  6 triplets  of  values)  / 
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5.2.2  Cockpit  Controls  Data 

The  user  will  utilize  the  command 

CONTROLS  = (240  character  descriptor)  / 
to  tell  the  program  that  control  definitions  are  to  follow.  After  this 
command  is  executed,  the  user  then  inputs  each  control  using  the  following 
commands . 

CODE  = (10  character  control  code)  / 

LOCATION  = (x,  y,  z values)  / 

EMBEDDED  PLANE  = (value)  / 

BASE  VERTEX  = (value)  / 

5.2.3  Eye  Reference  Points 

The  user  will  utilize  the  command 
EYE  REFERENCE  POINT  / 

to  introduce  a set  of  eye  reference  points  that  follow.  After  this  command 
is  executed,  the  user  then  inputs  each  eye  reference  point  using  the 
following  commands. 

LOCATION  = (x,  y,  z values)  / 

NAME  = (10  characters)  / 

5.2.4  Task  Sequence  Data 

The  user  will  utilize  the  command 
TASK  SEQUENCES  / 

to  initiate  the  task  sequence  subroutine.  After  this  command  the  user 
introduces  each  task  sequence  with  the  commands 

SEQUENCE  = (320  character  description)  / and 
SEQPARM  = (1  character  sequence  parameter)  / 

These  two  commands  must  be  executed  prior  to  the  following  commands  used 
to  define  each  sequence. 

TASK  NUMBER  = (value)  / 

TASK  DESCRIPTION  = (70  characters)  / 

LAND  CONTROL  CODES  = (10  characters),  (10  characters)  / 
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EYE  CONTROL  CODES  = (10  characters)  / 

FOOT  CONTROL  CODES  = (10  characters),  (10  characters)  / 

HAND  GRIP  CODES  = (value),  (value)  / 

DURATION  TIME  = (value)  / 

HOLDING  TIME  = (value)  / 

EULER  ANGLES  = (4  sets  of  x,  y,  z points)  / 

5.2.5  Control  Shapes  Data 

The  user  will  utilize  the  command 

CONTROL  SHAPES  = (240  character  descriptor)  / . 

After  this  command  is  executed,  the  user  then  inputs  each  control  shape 
using  the  following  commands. 

NAME  = (30  characters)  / 

PLANE  BOUNDARIES  = (value) , (value)  / 

5.3  User  Output  Specification 

Two  types  of  output  are  provided  by  the  DMS/CGE  interface  module; 
printed  reports  and  a punched  card  deck. 

5.3.1  Printed  Output 

A data  bank  report  is  obtained  as  follows. 

BEGIN  REPORT  GENERATOR  / 

REPORT  = CGEDATA  / 

END  REPORT  GENERATOR  / 

This  report  provides  the  user  with  a formatted  output  of  the  following: 

a.  CGE  cockpit  plane  data, 

b.  CGE  cockpit  controls  data, 

c.  CGE  task  sequence  data, 

d.  CGE  cockpit  shapes  data, and 

e.  CGE  eye  reference  point  data. 

From  this  report  the  user  may  easily  scan  his  input  data  to  check  for 
consistency  and  accuracy. 
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5.3.2  Punched  Output 


In  order  to  obtain  an  output  deck  of  cards  properly  formatted  in  CGE 
format,  the  user  will  use  the  following  commands. 

BEGIN  CGE  INTERFACE  / 

PUNCH  = CGEDATA 

TASK  SEQUENCES  = [LIST] 

CONTROL  SHAPES  = [LIST] 

CDDATA  = (LIST) 

EYE  REFERENCE  POINT  = (name)  / 

END  CGE  INTERFACE  / 

The  parameter  list  enclosed  in  brackets  is  an  option  parameter.  If  the 
user  specifies  the  LIST  option,  a card  image  listing  of  the  punched  output 
is  obtained  as  it  is  being  generated.  If  the  LIST  parameter  is  not  speci- 
fied, no  listing  is  obtained. 

The  TASK  SEQUENCES  and  CONTROL  SHAPES  commands  will  punch  a deck  of 
cards  from  the  data  bank  in  CGE  STORAGE  format.  The  output  and  formats  are 
shown  in  Tables  3 and  4. 

The  user  may  have  supplied  more  than  one  eye  reference  point  when  the 
data  bank  was  built  initially.  Thus,  when  the  CDDATA  punched  output  is 
desired,  the  additional  command,  EYE  REFERENCE  POINT  = (name)  /,  is  needed 
to  select  the  desired  eye  reference  point  from  those  previously  stored.  The 
(name)  is  the  name  of  the  eye  reference  point  desired  (parenthesis  not 
included) . 

The  CDDATA  command  will  punch  cards  in  CGE  CDDATA  format.  The  output 
formats  are  given  in  Table  5.  Since  three  commands  are  necessary  for 
obtaining  all  the  punched  output,  the  user  may  specify  any  combination  of 
these  commands  and  receive  a punched  deck  just  for  that  combination. 

5.4  The  DMS/CGE  Interface  Logic 

5.4.1  Ed ; tor  Subroutines 
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TASK  SEQUENCES  FORMAT 


Record 

Record 

Record 

Record 

Number 

Type 

"Column" 

Format 

Mnemonic 

Description 

(n4*l)  to 

Task 

1-80 

A10 

OUM1 ,DUM2, 

Task  sequence  descriptors 

(n4*4) 

Sequence 

DUM3.DUM4 

(dummies)  for  TASKSEQyxx 

(n4*S) 

1-2 

12 

NT1 

Total  number  of  tasks  in 

• 

, 

the  task  sequence. 

Cn4*S)* 

1-3 

13 

TASKNf8(I) 

Dimensioned  (20),  Task 

(3i-2) 

number 

11-80 

7A10 

TDES(K,I) 

Dimensioned  (7,20), 

(K-1,7) 

70  character  task 
description 

(n4*S) ♦ 

Task 

1-10 

A10 

RHTC(I) 

Dimensioned  (20), 

(3i-l) 

Sequence 

(cont.) 

Right  hand  control 
code 

11-20 

A10 

LHTC(I) 

Dimensioned  (20)  , 
Left  hand  control 
code 

21-30 

A10 

ETC (I ) 

Dimensioned  (20), 
Eye  control  code 

31-40 

A10 

RFTC(I) 

Dimensioned  (20), 

Right  foot  control 
code 


Table  3.  DMS/CGE  Task  Sequence  Format 
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TASK  SEQUENCES  FORMAT  (CONTINUED) 


Record 

Number 

Record 

Type 

Record 

"Column" 

Record 

Format 

Mnemonic 

Description 

41-SO 

A10 

LFTC(I) 

Dimensioned  (20), 
Left  foot  control 
code 

SI 

S6 

11 

11 

RHGC(I) 

LHGC(I) 

Dimensioned  (20), 
Right  hand  grip  code 
Left  hand  grip  code 
for  each  code, 
1-extended  hand 
3-clenched  hand 

61-67 

F7.3 

TDUR(I) 

Dimensioned  (20) , 
Task  duration  time 

68-78 

FI  1 . 3 

TH0LD(I) 

Dimensioned  (20) , Holding 
time  at  end  of  task 

(n4*S)* 

3i 

Task 

Sequence 

(cont.) 

1-15 

3FS.0 

RH0RT(L,I) 

(L-1,3) 

Dimensioned  (3,20), 

Euler  angles  for  right 
hand  orientation  (Theta, 
Phi,  Psi) 

16-30 

3F5.0 

LH0RT(L,I) 

(L-1,3) 

Dimensioned  (3,20), 

Euler  angles  for  left 
hand  orientation  (Theta, 
Phi,  Psi) 

31-45 

3FS.0 

RF0RT(L,I) 

(L-1,3) 

Dimensioned  (3,20), 

Euler  angles  for  right 
foot  orientation  (Theta, 
Phi,  Psi)  , 

46-60 

3FS.0 

LF0RT(L,I) 

(1-1.3) 

Dimensioned  (3,20), 
Euler  angles  for  left 

foot  orientation  (Theta, 
Phi,  Psi) 


N0TE:  These  three  card  images  are  repeated  for  i-1  to  NT1 . The  last  card  image  is 

denoted  n^. 


Table  3.  DMS/CGE  Task  Sequence  Format  (cont.) 
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CONTROLS  SHAPES  FORMAT 


Record  Number 

Record 

"Column" 

Record 

Format 

Description 

1 to  3 

80 

8A10 

•Control  shapes  descriptor 

3 ♦ 1 

1-30 

3A10 

Control  shape  name 

3 + 1 

31-35 

15 

Lower  plane  boundary 

3 + 1 

36-40 

15 

Upper  plane  boundary 

Table  4.  DMS/CGE  Control  Shapes  Format 
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CDDATA  FORMAT 

: 


RECORD 

NUMBER 

RECORD 

COLUMN 

RECORD 

FORMAT 

MNEMONIC 

DESCRIPTION 

1 

1-5 

15 

NERP 

TOTAL  NUMBER  OF  EYE  REFERENCE 
POINTS  IN  CREW  STATION. 

1-24 

3F8.3 

ERP(I.J) 

(1*1.3; 

J-l.NERP) 

LOCATION  OF  EACH  COCKPIT  EYE 
REFERENCE  POINT  IN  DESIGN 
COORDINATES  (BUTTOCK,  WATER, 
STATION  LINES) 

NERP+2 

1-5 

15 

IERP 

Eye  REFERENCE  POINT  NUMBER  TO 
BE  USED. 

6-15 

A10 

ERPNAM 

DESCRIPTIVE  10  CHARACTER  NAME  OF 
CHOSEN  EYE  REFERENCE  POINT. 

NERP+3 

NERP+4 

1-80 

8A10 

DESC(I.J) 

(1*1.2; 

0*1.8) 

TWO  COCKPIT  DATA  DESCRIPTOR  CARDS. 

NERP+5 

1-3 

13 

NPLANE 

TOTAL  NUMBER  OF  COCKPIT  PLANES 

1-37 

3A10, 

A7 

PLNAM(I.J) 

(1*1.4; 

0*1. 

NPLANE) 

COCKPIT  PLANE  NAME 

I 

38-40 

13 

OPL(O) 

(0*1, 

NPLANE) 

COCKPIT  PLANE  NUMBER 

41-42 

12 

NV  ( 0 ) 
(0*1. 
NPLANE) 

NUMBER  OF  VERTICES 

I +1,1+2 

1-72 

9F8.2 

PPT(K.I.O) 
(K=l ,3;  1*1 
NV(O) ;0*1 
1 .NPLANE 

COCKPIT  PLANE  VERTICES  IN 
DESIGN  COORDINATES 

RECORDS  I,  1+1,  1+2  ARE  REPEATED  UNTIL  ALL  "NPLANE"  PLANES  ARE  SPECIFIED. 


Table  5.  CDDATA  Format 


CDDATA  FORMAT 
(continued) 


RECORD 

NUMBER 

RECORD 

COLUMN 

m 

MNEMONIC 

DESCRIPTION 

1-80 

8A10 

DESK(I.J) 

(1=1,2; 

(J=l,8) 

CONTROLS  DATA  SET  DESCRIPTOR  CARDS. 

M+4 

1-3 

mm 

NCC 

NUMBER  OF  CONTROL  CODES 

1-10 

A10 

CC0DE( J) 
(J-l.NCC) 

CONTROL  CODE  UP  TO  10  CHARACTERS. 

.1 

11-40 

3F10.3 

C(I,J) 
(1=1,3; 
J=1 ,NCC) 

CONTROL  POINT  COORDINATES  OR 
DISTANCES,  ALONG  X & Y EDGES, 
FROM  SPECIFIED  VERTEX  IVN0 
(3RD  OR  "Z"  - COORDINATE  BLANK) 

43-45 

13 

IP(J) 

(J-l.NCC) 

PLANE  NUMBER  OF  EMBEDDED  CONTROL 
(BLANK  IF  NOT  EMBEDDED) 

48-50 

13 

IVNO(J) 
(J=l ,NCC) 

VERTEX  NUMBER  ON  PLANE  NUMBER 
IP(J)  TO  BE  USED  AS  ORIGIN  IN 
CALCULATING  X,  Y,  Z COORDINATES  OF 
CONTROL  POINT. 

RECORD  J IS  REPEATED  UNTIL  "NCC"  CONTROL  POINTS  HAVE  BEEN  SPECIFIED. 


Table  5.  CDDATA  Format  (cont.) 
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I 

When  the  command  BEGIN  CGE  INPUT  is  encountered,  the  CAFES  editor  subrou- 
tine CGEGE  will  be  entered.  This  is  a control  program  which  will  call 
five  other  subroutines.  These  subroutines  are  as  follows. 

CEPLANE  - reads  cockpit  planes  data  nad  places  it  in  the  cockpit  planes 
category . 

CECODE  - reads  cockpit  controls  data  and  places  it  in  the  cockpit  controls 
category . 

CEEYE  - reads  eye  reference  point  data  and  places  it  in  the  eye  reference 
category . 

CETSK  - reads  task  sequence  data  and  places  it  in  the  task  sequence 
category . 

CESHAP  - reads  control  shapes  data  and  places  it  in  the  control  shapes 

category.  In  addition,  the  main  program  will  store  the  descrip- 
tion in  the  CGE  descriptor  category. 

A macro  flowchart  of  this  process  is  shown  in  Figure  14. 

5.4.2  Report  Generation  Subroutines 

When  the  command 
REPORT=CGEDATA 

is  encountered  while  in  the  Report  Generation  mode,  a formatted  output  of 
all  CGE  data  stored  in  the  data  bank  is  obtained.  Subroutine  CRCGE  is 
used  to  produce  this  output.  Subroutine  CRCGE  is  entered  when  a command 
of  the  form 

REPORT=CGEDATA/ 

is  encountered  while  in  the  Report  Generation  mode.  This  routine  provides 
a complete  formatted  dump  of  all  data  stored  in  the  CGE  data  bank  categories 
81  through  87.  Since  this  routine  is  a data  bank  report  routine,  it  is  a 
part  of  OVERLAY  (CAFES,  3,  1). 

5.4.  ’■  DNS' CGE  Interface  Module  Subroutine 


Program  CGCGE  is  the  main  overlay  program  for  controlling  the  generation 
data  oj  the  CGE  program.  The  data  is  generated  in  two  possible  ways, 
st  is  simply  to  output  previously  stored  CGE  data  from  the  data 
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Figure  14.  Macro-Flow  of  CECGE 
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bank  on  to  cards  in  CGE  format.  The  second  is  output  previously  stored 
CAD  data  in  CGE  format. 

The  CGCGE  program  is  entered  when  a command  of  the  form 
BEGIN  CGE  INTERFACE/ 

is  encountered  in  the  CAFES  input  stream.  To  allow  for  punching  of 
previously  stored  CGE  data,  the  following  command  is  used. 

PUNCH  CGEDATA/ 

followed  by  any  combination  of  the  three  commands, 

cddata=[list]  / 

TASK  SEQUENCES' [LIST]  / 

CONTROL  SHAPES' [LIST]/. 

The  first  command  will  punch  out  the  data  for  the  CDDATA  model  of  CGE. 
The  second  two  commands  will  punch  out  two  portions  of  the  data  required 
by  the  STORAGE  model  of  CGE. 

In  order  to  punch  CAD  data  into  CGE  format,  the  command 
PUNCH'CDDATA/ 

is  used.  The  CGCGE  program  is  exited  when  a command  of  the  form 
END  CGE  INTERFACE/ 

is  encountered  and  control  is  passed  back  to  overlay  (1,0) . Figure  15 
shows  a macro  flow  of  the  interface  module. 


Figure  15.  CAFES/CGE  Interface  Module  Flow 
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5.5  Data  Bank  Category  Formats 


The  formats  for  the  DMS/CGE  Interface  Module  data  bank  categories 
are  shown  in  the  following  tables. 
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Category  Typo:  PRIMARY 
Category  Number:  33 
Category  Name:  COCKPIT  CONTROLS 

Word 

— 

Parameter 

Number 

Variable 

Name 

Parameter  Name 

Parameter 

Type 

Number  of 
Words  or 
Characters 

Secondary 

Category 

Usage 

CONTROL  CODE 
LOCATION  (X,  Y,  Z) 
EMBEDDED  PLANE 
BASE  VERTEX 


CHARACTER 

FLOATING 

INTEGER 

INTEGER 


Table  6.  Format  for  DMS/CGE  Data  Bank  Categories  (cont.) 


Table  6.  Format  for  DMS/CGE  Data  Bank  Categories  (cont.) 
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Parameter 

Number 


Variable 

Name 


Table  6.  Format  for  DMS/CGE  Data  Bank  Categories  (cont.) 


1 

2 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

21 

21 

24 

27 

NOTE: 

This 

desc 

Category  Type;  PRIORY 
Category  Number;  35 
Category  Name;  TASK  SEQUENCES 


Parameter  Name 

Parameter 

Type 

Number  of 
Words  or 
Characters 

Secondary 

Category 

Usage 

TASK  NUMBER 

INTEGER 

1 

TASK  DESCRIPTION 

CHARACTER 

7 

RIGHT  HAND  CONTROL  CODE 

CHARACTER 

1 

LEFT  HAND  CONTROL  CODE 

CHARACTER 

1 

EVE  CONTROL  CODE 

CHARACTER 

1 

RIGlfT  FOOT  CONTROL  CODE 

CHARACTER 

1 

LEFT  FOOT  CONTROL  CODE 

CHARACTER 

1 

RIGHT  HAND  GRIP  CODE 

INTEGER 

1 

LEFT  HAND  GRIP  CODE 

INTEGER 

1 

TASK  DURATION  TIME 

FLOATING 

1 

HOLD  TIME  AT  END  OF 
TASK 

FLOATING 

1 

EULER  ANGLES  FOR  RIGHT 
HAND  ORIENTATION 

FLOATING 

3 

EULER  ANGLES  FOR  LEFT 
HAND  ORIENTATION 

BOATING 

3 

EULER  ANGLES  FOR  RIGHT 
TOOT  ORIENTATION 

FLOATING 

3 

EULER  ANGLES  FOR  LEFT 
FOOT  ORIENTATION 

BOATING 

3 

al  sets  of  tasks  which  f 
■t  number  is  given  in  cat 

>rm  a unique 
?go ry  87. 

task  sequence. 

The  task  sequence 

Category  Type;  PRIMARY 
. Category  Number:  86 

Category  Name:  CONTROL  SHAPES 

Vord 

Parameter 

Number 

Variable 

Name 

Parameter  Name 

Parameter 

Type 

Number  of 
Words  or 
Characters 

Secondary 

Category 

Usage 

CONTROL  SHAPE  NAME  CHARACTER 

UPPER  PLANE  BOUNDARY  INTEGER 

LOWER  PLANE  BOUNDARY  INTEGER 


Table  6.  Format  for  DMS/CGE  Data  Bank  Categories  (cont.) 


Table  6.  Format  for  DMS/CGE  Data  Bank  Categories  (cont.) 
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6.0  CONSOLE  SPACE  OPTIMIZATION  AND  LAYOUT  EVALUATION  MODEL  (CONSOLE) 


Th4  capability  of  the  Computer-Aided  Design  (CAD)  Model  to  describe 
controls  and  displays  was  extended  during  Phase  V of  the  CAFES  Program  by 
the  specification  of  preliminary  requirements  for  a CONsole  Space  Optimi- 
zation and  Layout  Evaluation  (CONSOLE)  Model.  The  first  step  in  this 
effort  was  to  define  the  general  requirements  for  an  automated  panel  space 
allocation  routine.  Then,  a survey  of  the  literature  on  computer-aided 
optimization  techniques  was  conducted.  Since  an  adequate  computer-aided 
method  for  allocating  panel  space  and  for  arranging  controls  and  displays 
was  not  found,  a new  procedure  was  developed.  Ground  rules  for  the  new 
computer  model  were  established.  An  appropriate  function  for  the  allocation 
of  panel  space  was  defined  and  the  parameters  to  be  used  in  the  optimization 
routines  were  identified.  From  this  base,  an  analytical  approach  was 
developed  for  the  CONSOLE  Model. 

CONSOLE  is  being  developed  to  assist  crewstation  designers  in  deter- 
mining the  optimal  size  and  spatial  arrangement  for  functionally  related 
groups  of  controls  and  displays.  The  following  section  will  contain  a 
description  of  the  general  requirements  and  objectives  of  the  CONSOLE 
Model,  the  CONSOLE  concept,  and  CONSOLE  input  requirements,  computing 
routines  a;  i outputs. 

6.1  Introduction 

The  purpose  of  this  specification  is  to  provide  a broad  outline  of 
desired  capabilities  and  a set  of  general  requirements  for  an  initial 
conceptualization  of  a CONSOLE  Space  Optimization  and  Layout  Evaluation 
(CONSOLE)  Model.  CONSOLE  will  be  developed  as  a submodel  of  the  Computer- 
Aided  Design  (CAD)  Model  and  will  operate,  initially,  in  a batch  mode.  The 
overall  objective  of  CAD  is  to  assist  engineers  in  the  design  and  evaluation 
of  crewstations  for  Naval  Systems.  A fundamental  step  in  the  design  process 
involves  the  allocation  of  panel  space  to  aircraft  subsystems  and  the  deter- 
mination of  a physical  arrangement  for  those  subsystems.  An  automated 


procedure  for  accomplishing  these  tasks  must  be  developed  if  the  CAD  Model 
is  to  become  a viable  design  tool.  CONSOLE  will  fulfill  this  requirement. 
The  role  of  the  CONSOLE  program  and  it's  relationship  to  the  tasks  performed 
by  the  crewstation  or  the  subsystems  designer  is  discussed  in  the  following 
paragraphs . 

The  distinction  between  the  crewstation  designer  and  the  subsystem 
designer  should  be  noted.  The  crewstation  designer  has  the  responsibility 
of  taking  the  parameter  lists  or  individual  subsystem  panel  layout  sketches 
from  the  subsystem  designers  and  incorporating  them  into  the  proper  crew- 
station layout  along  with  all  the  appropriate  system  requirements.  It  is 
generally  his  job  to  question  the  value  of  each  of  the  displays  or  controls 
and  to  find  out  such  things  as  the  criticality  and  frequency  of  use  of  each. 
There  are  generally  several  subsystem  designers  for  every  crewstation 
designer.  There  may  be  one  in  charge  of  all  aspects  of  several  subsystems 
(e.g.,  electrical,  hydraulic,  etc.)  or  more  often,  one  or  more  for  each 
individual  subsystem.  It  is  their  job  to  determine  each  of  the  particular 
subsystem  parameters  that  should  require  display  or  control.  They  should 
also  provide  the  rationale  for  the  existence  of  the  parameters  displayed  or 
controlled . 


Both  crewstation  and  subsystem  designers  must  deal  with  many  problems 
when  deve loping  a new  crewstation  configuration.  Some  of  these  problems 
include:  What  controls  and  displays  are  required?  How  large  should  this 

display  be?  Where  should  this  control  be  placed?  Can  an  existing  control 
be  used  for  this  function  or  must  a new  control  be  developed?  The  designer, 
either  crewstation  or  subsystem,  must  perform  many  complex  tradeoffs  in  his 
efforts  to  effect  an  optimum  compromise  that  will  satisfy  all  system  require- 
ments. He  often  relies  heavily  upon  his  past  experience  in  performing  these 
tradeoffs.  This  reliance  has  been  justified  by  a reduction  in  development 
costs  since  many  time  consuming  decisions  can  be  omitted  for  the  new  system 
development  program.  A limited  reliance  upon  past  experience  may  be  prudent 
but  an  extensive  reliance  may  actually  produce  negative  effects  by  inhibit- 
ing required  design  changes  and  by  perpetuating  faulty  crewstation  designs. 
Exam 1 ~s  of  such  negative  effects  are  illustrated  in  the  following  paragraphs. 
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In  the  first  example,  a subset  of  controls  and  displays  from  a prior 
system  development  program  may  be  included  in  a new  configuration  even 
though  the  controls  and  displays  are  no  longer  required.  The  designer  can- 
not make  significant  contributions  to  the  development  process  when  changes 
in  crewstation  design  fail  to  keep  pace  with  the  changing  information  require- 
ments of  advanced  aircraft.  If  a designer  borrows  too  extensively  from  his 
past  experience,  he  may  not  realize  that  the  requirements  for  a new  system 
have  changed.  In  this  case,  reliance  upon  past  experience  will  function  to 
inhibit  design  changes. 

In  a second  example,  one  or  more  of  the  controls  and  displays  from  a 
prior  system  may  have  been  ill  suited  to  the  older  system.  The  poorly 
designed  equipment  may  have  been  detected  in  the  test  and  evaluation  phase 
of  the  procurement  cycle  but  were  left  unchanged  due  to  the  extreme  cost  of 
a retrofit  and  to  the  proven  adaptability  of  the  pilot  population.  A 
designer  relying  upon  his  past  experience  may  use  the  same  faulty  equipment 
in  a new  system  development  program.  Thus,  he  will  actually  perpetuate  a 
crewstation  design  error  that  has  already  been  identified. 

The  crewstation  designer  must  also  deal  with  another  problem.  That  is, 
what  to  do  with  new  instruments  that  have  been  developed  to  meet  the  changing 
information  requirements  of  advanced  aircraft.  There  are  at  least  two  pit- 
falls  here.  First,  the  newly  developed  equipment  may  simply  be  added  to  a 
growing  list  of  controls  and  displays  even  though  the  information  it  contains 
is  partially  or  totally  redundant  with  information  provided  by  existing 
instruments.  In  this  case,  the  designer  will  be  wasting  limited  panel  real 
estate  by  an  unnecessary  duplication  of  hardware.  On  the  other  hand,  estab- 
lished controls  and  displays  may  be  discarded  to  accommodate  a new  piece  of 
equipment  which  is  assumed  to  perform  the  same  function.  In  reality,  the 
new  equipment  may  only  partially  replicate  the  function  of  the  discarded 
controls  and  displays.  In  this  case,  the  designer  has  unwittingly  sacri- 
ficed a required  function  in  his  quest  to  economize  the  available  panel 


A possible  third  pitfall  is  that  of  allocating  space  and  positional 
priority  to  displays  and  controls  that  are  indeed  required  from  previous 
systems.  Whereas  there  may  be  several  reasons  to  keep  the  same  relative 
configuration,  the  decision  cannot  be  based  solely  on  their  use  in  the 
previous  system.  As  newer  systems  evolve  the  priorities  for  use  of  display 
and  control  parameters  tend  to  change.  Accordingly  their  space  and  position 
assignments  should  be  re-evaluated. 

In  view  of  the  heavy  recall  requirements  and  the  complexity  of  the 
tradeoffs  that  must  be  performed,  it  would  not  be  surprising  if  the  crew- 
station  designer  were  unable  to  describe  the  methods  he  used  during  the 
design  development  process.  Such  a lack  of  accountability  has  several  nega- 
tive implications  for  the  overall  system  development  program.  In  the 
absence  of  an  explicit  record  of  the  tradeoffs,  assumptions  and  recall  of 
information  from  prior  efforts,  the  crewstation  designer  may  be  unable  to 
defend  his  recommendations.  Thus,  the  credibility  and  the  importance  of  his 
inputs  to  the  system  development  program  may  be  seriously  questioned. 

CONSOLE  is  being  developed  to  help  crewstation  designers  cope  with  the 
traditional  design  problems  discussed  above.  CONSOLE  will  facilitate  the 
design  development  process  in  the  following  ways: 

(a)  It  will  reduce  design  time  by  automating  many  routine  tasks.  Thus, 
the  designer  will  be  able  to  devote  a greater  proportion  of  his 
time  to  the  complex  tradeoff  decisions  that  must  be  performed. 

(b)  It  will  reduce  demands  upon  the  designer's  immediate  memory  by 
keeping  track  of  many  complex  interrelationships  among  the  controls 
and  displays  of  all  aircraft  subsystems. 

(c)  It  will  provide  a systematic  approach  to  the.  panel  layout  problem 
that  will  enable  the  designer  to  discover  his  errors  more  rapidly 

nd  to  initiate  design  modifications  more  easily. 
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(d)  It  will  provide  the  designer  with  an  explicit  record  of  the  design 
decision  process. 

6.2  CONSOLE  Design  Objectives 

The  primary  objectives  of  the  CONSOLE  Model  are  to  design  a computer 
program  that  will: 

(a)  allocate  panel  space  to  major  aircraft  subsystems  or  related 
control/display  functional  groupings  according  to  some  rational 
and  equitable  objective  functions, 

(b)  arrange  aircraft  subsystems  on  a panel  in  such  a way  as  to  maxi- 
mize their  usefulness,  thereby  insuring  that  all  mission  objectives 
may  be  accomplished  in  an  efficient  manner, 

(c)  have  a simple  user  interface  requiring  a limited  number  of  inputs 
and  having  a great  deal  of  flexibility  with  regard  to  input 
format , 

(d)  insure  a high  degree  of  involvement  in  the  design  decision  process 
by  the  crewstation  designer, 

(e)  generate  both  tabular  and  graphical  outputs  useful  to  the  crew- 
station  designer. 

CONSOLE  is  being  developed  as  a subprogram  of  the  CAD  Model.  By  utilizing 
several  existing  features  of  the  CAD  software,  (e.g.,  coordinate  conversion 
routines,  CAD  element  dictionary,  scaling  routines,  etc.)  it  is  believed 
that  all  of  the  objectives  listed  above  can  be  successfully  accomplished. 

6.3  The  CONSOLE  Concept 

The  primary  idea  behind  the  CONSOLE  Model  is  that  all  good  panel  layout 
designs  must  incorporate  certain  basic  characteristics.  CONSOLE  represents 
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an  attempt  to  define  these  characteristics  and  to  integrate  them  into  a com- 
puter model  that  can  be  systematically  applied  to  crewstation  design  prob- 
lems. The  following  paragraphs  discuss  several  aspects  of  the  CONSOLE  Model 
that  are  crucial  considerations  for  any  automated  panel  layout  procedure. 


One  critical  consideration  concerns  the  accessibility  of  various  loca- 
tions within  a crew  workstation.  Obviously,  the  most  important  controls  and 
displays  should  be  placed  in  the  most  accessible  locations.  The  accessibi- 
lity problem  can  be  solved  by  partitioning  the  available  panel  space  into 
several  zones.  A zone  that  is  located  directly  in  front  of  an  operator  and 
in  the  center  of  a panel  will  generally  be  more  accessible  than  any  other 
area  on  the  panel.  Therefore,  the  most  centrally  located  zone  is  given  the 
highest  priority  rating.  The  priority  assigned  to  a zone  decreases  as  the 
distance  between  the  zone  and  the  center  of  the  panel  increases.  Side  panels 
and  panel  space  behind  an  operator  are  given  the  lowest  priority  ratings. 

This  zoning  procedure  enables  the  model  user  to  deal  with  the  relationship 
between  an  instruments  accessibility  requirements  and  its  location  upon  a 
panel. 


6.3.2  Balance  of  Real  and  Ideal 


CONSOLE  will  provide  the  crewstation  designer  with  two  types  of  panel 
layouts;  an  idealized  layout  design  and  a pragmatic,  or  realistic,  layout 
design.  The  goal  of  the  idealized  layout  will  be  to  optimize  both  the  size 
and  the  spatial  location  of  subsystem  controls  and  displays.  The  optimiza- 
tion routines  used  to  generate  such  layouts,  however,  are  often  insensitive 
to  realistic  design  constraints  and  requirements  such  as  standards  for  the 
size  and  shape  of  controls  and  displays  and  the  alignment  of  controls  and 
displays  with  supporting  structures  behind  the  panel.  Therefore,  the  ideal! 
zed  panel  layout  model  must  impose  some  type  of  restriction  upon  the  size 
and  sh^e  of  the  computer  generated  controls  and  displays.  These  restric- 
tions might  include  the  following:  no  control  or  display  shall  be  allocated 

a surface  area  that  is  smaller  than  a specified  minimum  area;  no  control  or 
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display  shall  be  allocated  a surface  that  is  larger  than  a specified  maximum 
area;  and  all  controls  and  displays  will  be  rectangular  in  shape.  A com- 
puter model  without  such  restrictions  will  generate  panel  layouts  in  which 
many  controls  and  displays  are  characterized  by  complex  geometric  shapes 
and/or  unrealistic  sizes.  Even  with  these  restrictions,  however,  the  amount 
of  space  allocated  to  controls  and  displays  by  the  idealized  model  will 
generally  differ  from  the  size  of  existing  controls  and  displays. 

Since  we  do  not  generally  have  this  much  flexibility  in  the  real  world, 
a more  realistic,  or  pragmatic,  layout  design  must  also  be  generated.  Out- 
puts of  the  pragmatic  model  will  be  constrained  by  the  use  of  existing  mili- 
tary standards  for  the  shape  and  size  of  all  controls  and  displays  and  by 
arranging  the  controls  and  displays  so  that  they  are  aligned  with  the  struc- 
tural supports  behind  the  panel.  Thus,  the  pragmatic  model  will  be  more  con- 
cerned with  optimizing  the  spatial  relationships  among  all  functional  groups 
of  controls  and  displays  than  with  optimizing  the  amount  of  space  that  is 
allocated  to  the  functional  groups.  By  having  both  types  of  layout  designs, 
the  designer  can  use  the  idealized  layout  to  obtain  valuable  information 
concerning  panel  design  tradeoffs  that  must  be  made  for  incorporation  into 
the  realistic  layout  design. 

6.3.3  Functional  Grouping 

Another  important  consideration  concerns  the  interrelationship  between 
various  aircraft  subsystems.  A superior  panel  layout  should  minimize  the 
distance  traveled  by  both  hand  and  eye  in  performing  a sequence  of  tasks  and 
also  minimize  the  time  required  to  perform  the  sequence  of  tasks.  To  achieve 
these  goals,  an  automated  panel  layout  procedure  must  consider  the  inter- 
relationships between  all  aircraft  subsystems.  If  workloads  are  to  be  mini- 
mized, subsystems  that  are  highly  related  to  one  another  must  occupy  adjacent 
locations  on  a panel.  This  same  principle  also  applies  to  individual  con- 
trols and  displays. 
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6.3.4  Criticality,  Utilization  and  Information  Transfer 

• 

A fourth  consideration  involves  several  attributes  that  are  shared  in 
common  by  all  controls  and  displays.  Every  control  and  display  can  be 
described  in  terms  of  its  criticality,  frequency  of  use,  and  the  amount  of 
information  it  transmits  to  an  operator  per  unit  of  time . Both  the  amount 
of  panel  space  allocated  to  a control  or  display  and  the  location  of  the 
control  or  display  upon  a panel  should  be  a function  of  these  three  primary 
characteristics.  As  a general  rule,  displays  and  controls  that  are  highly 
critical  for  flight  safety  and  for  mission  success  should  be  given  a greater 
proportion  of  the  panel  space  and/or  should  be  located  in  the  most  acces- 
sible areas.  In  a similar  manner,  controls  and  displays  that  are  used  most 
frequently  and  that  transmit  the  most  information  per  unit  of  time  should 
also  be  given  a greater  proportion  of  the  panel  area  and/or  should  be  placed 
in  the  most  accessible  areas.  It  should  be  noted  that  the  values  assigned 
to  the  information  transfer  characteristic  will  vary  considerably  from  one 
display  to  another.  The  information  transfer  characteristic  should  be 
defined  in  such  a way  as  to  handle  the  distinction  between  multifunction 
and  single  function  controls  and  displays  and  between  controls  and  displays 
that  operate  in  a continuous  as  opposed  to  a discrete  manner. 

Upon  closer  examination,  it  soon  becomes  apparent  that  all  controls 
and  displays  do  not  possess  equal  degrees  of  each  of  the  three  character- 
istics. That  is,  a particular  display  may  be  monitored  quite  frequently 
even  though  it  has  a relatively  low  rate  of  information  transmission  and  is 
only  moderately  critical  for  flight  safety.  From  this  example,  it  is  clear 
that  the  three  characteristics  must  be  combined  in  some  manner  in  order  to 
determine  the  appropriate  panel  location  and  the  amount  of  space  that  should 
be  allocated.  Thus,  some  type  of  an  objective  function  is  required  to  deter- 
mine the  relative  contribution  of  the  three  characteristics. 

6.3.'  Military  Specifications  and  Standards 

The  automated  panel  layout  procedure  must  generate  configurations  that 
ire  c s'  tent  with  the  restrictions  imposed  by  military  specifications  and 
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v military  standards.  Hence,  the  user  must  have  some  method  by  which  he  can 

specify  mandatory,  as  well  as  desired,  locations  for  the  placement  of  con- 
trols and  displays. 

V.  / 

6.4  CONSOLE  Input  Requirements 

CONSOLE  will  be  used  to  assist  the  crewstation  designer  in  the  develop- 
l ment  of  preliminary  crewstation  configurations.  From  CONSOLE,  the  designer 

will  obtain  an  initial  estimate  of  the  amount  of  space  that  should  be 
assigned  to  various  aircraft  subsystems  (e.g.,  fuel  management,  engines, 
navigation,  communications,  weapons  management,  sensors,  etc.)  and  a scheme 
for  the  spatial  organization  of  the  subsystems  upon  a panel.  The  following 
paragraphs  describe  the  tasks  that  must  be  performed  by  the  crewstation 
designer  in  order  to  prepare  the  inputs  required  by  the  CONSOLE  Model. 

A small  number  of  inputs  will  be  required  to  execute  the  CONSOLE  Model. 
First,  a crewstation  workspace  must  be  defined  by  providing  two-dimensional 
coordinates  (all  in  the  same  local  coordinate  system)  for  the  following 
geometric  items:  the  entire  surface  area  of  the  panel  that  is  available 

for  control/display  placement;  all  structural  supports  for  mounting  items  on 
the  panel;  and  all  zones  of  differing  priority  on  the  panel.  Then,  the 
acceptable  shapes  and  sizes  for  all  functional  groups  must  be  defined  by 
providing  the  two-dimensional  coordinates  for  all  standard  military  panel 
units  (that  are  separate  functional  entities)  that  are  to  be  considered  for 
the  problem.  All  controls  and  displays  to  be  placed  on  the  total  CONSOLE 
panel  area  must  be  identified  and  assigned  to  a functional  group. 

The  following  information  must  be  provided  for  each  control  and  display: 
the  two-dimensional  coordinates;  a criticality  rating;  a frequency  of  use 
rating;  a functional  group  assignment,  and  an  estimate  of  the  amount  of 
information  it  transmits.  The  criticality  score  will  be  obtained  by  evalu- 
ating each  control  or  display  against  a five-point  scale.  The  rater  will 
assume  that  each  successive  control  or  display  has  ceased  to  function  and 
will  then  select  one  of  the  following  criticality  scores:  (5)  Flight  safety 

is  lost;  (4)  Mission  must  be  aborted;  (3)  Flight  safety  and/or  mission 
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success  will  be  degraded;  (2)  Alternative  techniques  must  be  used  and/or 
there  will  be  an  increase  in  crew  workload  but  without  degradation  of  flight 
safety  or  mission  success;  and  (1)  The  failure  has  no  effect.  Each  of  the 
criticality  scores  is  used  as  a weighting  factor  in  the  determination  of  a 
panel  space  allocation.  It  should  be  noted  that  the  exact  relative  weight 
of  each  criticality  score,  or  number,  has  not  as  yet  been  determined.  As 
the  program  receives  more  use, a more  accurate  determination  of  these  relative 
values  will  be  made.  The  frequency  of  use  rating  will  be  obtained  by  esti- 
mating the  percent  of  the  mission  time  that  the  particular  control  or  dis- 
play will  be  used.  The  amount  of  information  transmitted  by  a control  or 
display  will  be  represented  by  an  integer  number,  with  larger  numbers 
indicating  greater  amounts  of  information  transmission.  The  magnitude  of 
the  information  transmission  score  will  be  greater  for  multifunction  than 
for  single  function  controls  and  displays  and  for  controls  and  displays  that 
operate  in  a continuous  manner.  Whereas  the  quantity  of  BITS  in  a discrete 
display  or  control  is  easily  determined,  the  quantification  of  information 
transmission  for  continuous  displays  or  controls  is  much  more  difficult.  It 
has  been  suggested  that  4 bits  be  used  as  an  average  value  for  continuous 
displays  and  controls.  Additional  effort  needs  to  be  made  to  determine  the 
best  method  of  quantifying  continuous  information  transmission. 


Finally,  the  following  information  must  be  provided  for  each  function 

group:  the  group  name;  the  two-dimensional  coordinates  for  the  group;  re- 

a 

strictions  on  geometric  placement  with  mandatory  locations  defined  by  the 
two-dimensional  coordinates  for  the  centroid  of  the  group  and  with  desired 
locations  defined  by  a zone  number;  and  the  degree  of  relationship  to  other 
functional  groups  with  a one  (1)  defining  a high  degree  of  relationship  and 
a two  (2)  defining  a moderate  degree  of  relationship. 

Figure  16  illustrates  the  CONSOLE  input  format  for  a set  of  hypothetical 
data.  It  should  be  noted  that  the  coordinates  specified  in  the  STRUCTURAL 
SUPPORT  DATA  section  and  in  the  ZONE  DATA  section  are  in  terms  of  the  CONSOLE 
coordinate  system.  The  coordinates  specified  for  each  runctional  group  are 
ii  t -rms  of  the  appropriate  coordinates  in  the  ZONE  DATA  section  while  the 
coordinates  associated  with  specific  controls  and  displays  are  in  terms 
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CONSOLE  COORDINATES  = 0,0  30,0  30,25  0,25/ 

>.  ' STRUCTURAL  SUPPORT  DATA/ 

1 - 0,0  1,0  1,25  0,25/ 

2 = 10,0  11,0  11,25  10,25/ 

'V  s 

3 - 20,0  21,0  21,25  20,25/ 

A = 29,0  30,0  30,25  29,25/ 

ZONE  DATA/ 


AA  * 

0,0 

10,0 

10,25 

0,25/ 

V 

3 “ 

10,0 

20,0 

20,10 

10,10/ 

1 = 

10,10 

20,10 

20,20 

10,20/ 

X • . 

2 = 

10,20 

20,20 

20,25 

10,25/ 

AB  = 

20,0 

30,0 

30,25 

20,25/ 

STANDARDIZED  PANEL  DATA/ 


1 « 

0,0 

10,0 

10,2 

0,2/ 

2 = 

0,0 

10,0 

10,3 

0,3/ 

3 = 

0,0 

10,0 

10, A 

0,  A/ 

A ■ 

0,0 

10,0 

10,5 

0,5/ 

5 = 

0,0 

10,0 

10,6 

0,6/ 

FUNCTIONAL  GROUP  = ENGINE  SUBSYSTEM/ 

COORDINATES  - 0,0  10,0  10,6  0,6/ 

PLACEMENT  = ZONE  1/ 

RELATIONSHIPS  = THROTTLE  (1)/ 

DISPLAY  DATA/ 

NAME  = RPM/ 

COORDINATES  = 0,0  2.5,0  2.5,6  0,6/ 

CRITICALITY  = 3/ 

FREQUENCY  -=35/ 

INFORMATION  - 2/ 

NAME  = TURBINE  OUTLET  PRESSURE/ 

COORDINATES  = 2.5,0  5,0  5,6  2.5,6/ 

CRITICALITY  - A/ 

FREQUENCY  = 50/ 

INFORMATION  * 2/ 

NAME  - TURBINE  OUTLET  TEMPERATURE/ 

COORDINATES  - 5,0  7.5,0  7.5,6  5,6/ 


Figure  16.  CONSOLE  Input  Format 


CRITICALITY  = 4/ 

FREQUENCY  = 50/ 

INFORMATION  = 2/ 

NAME  = FUEL  FLOW/ 

COORDINATES  = 7.5,0  10,0  10,6  7.5,6/ 

CRITICALITY  = 1/ 

FREQUENCY  =25/ 

INFORMATION  =2/ 

FUNCTIONAL  GROUP  = PRIMARY  ATTITUDE  INDICATOR/ 

COORDINATES  = 0,0  10,0  10,4  0,4/ 

PLACEMENT  = 15,18/ 

RELATIONSHIPS  = ALTIMETRY  SUBSYSTEM  (1),  AIRSPEED  SUBSYSTEM  (1)/ 
DISPLAY  DATA/ 

NAME  = ATTITUDE  INDICATOR/ 

COORDINATES  = 0,1  10,1  10,4  0,4/ 

CRITICALITY  = 5/ 

FREQUENCY  =75/ 

INFORMATION  = 3/ 

CONTROL  DATA/ 

NAME  = CONTRAST  SELECTOR/ 

COORDINATES  = 0,0  3.33,0  3.33,1  0,1/ 

CRITICALITY  = 1/ 

FREQUENCY  =5/ 

INFORMATION  = 1/ 

NAME  = BRIGHTNESS  SELECTOR/ 

COORDINATES  = 3.33,0  6.66,0  6.66,1  3.33,1/ 

CRITICALITY  = 1/ 

FREQUENCY  =5/ 

INFORMATION  =1/ 

NAME  = MODE  CONTROL/ 

COORDINATES  = 6.66,0  10,0  10,1  6.66,1/ 

CRITICALITY  = 1/ 

FREQUENCY  =15/ 

INFORMATION  = 1/ 


Figure  16.  CONSOLE  Input  Format  (cont.) 


of  the  FUNCTIONAL  GROUP  coordinates.  When  a functional  group  must  be  placed 
in  a fixed  location  on  the  console  (as  the  primary  attitude  indicator  in 
this  example)  the  coordinates  for  the  centroid  of  that  group  are  specified 
in  terms  of  the  appropriate  coordinates  in  the  ZONE  DATA  section. 

6.5  CONSOLE  Computing  Functions 

6.5.1  Allocation  of  Panel  Space 


The  CUBITS  concept  developed  by  CDR  R.  J.  Wherry,  Jr.,  NADC.will  be 
used  for  the  panel  space  optimization  function  of  the  CONSOLE  Model.  The 
CUBITS  concept  is  based  upon  the  characteristics  that  are  shared  by  all 
controls  and  displays:  criticality,  frequency  of  utilization  and  amount 

of  information  transmitted  (BITS).  The  optimal  amount  of  space  that  should 
be  allocated  to  a control  or  display  can  be  obtained  from  the  CUBITS  formula: 
Space  - Criticality  X Utilization  X BITS.  Since  the  initial  CONSOLE  Model 
will  deal  with  groups  of  controls  and  displays  that  are  functionally  re- 
lated, the  CUBITS  scores  calculated  for  each  control  and  display  within 
the  functional  group  must  be  summed.  The  CUBITS  scores  will  then  be  summed 
over  all  of  the  functional  groups.  The  optimal  percent  of  the  panel  space 
allocated  to  a functional  group  will  be  calculated  by  dividing  the  CUBITS 
score  of  each  functional  group  by  the  sum  of  the  CUBITS  scores  for  all  func- 
tional groups.  The  optimal  area,  in  terms  of  panel  space,  for  each 
functional  group  will  then  be  calculated  by  multiplying  the  percent  of  the 
panel  space  allocated  to  each  functional  group  by  the  total  surface  area 
of  the  panel. 

The  CONSOLE  computing  routines  will  then  calculate  the  area  for  each 
functional  group  from  the  group's  coordinates.  If  the  amount  of  space  alloca- 
ted to  a functional  group  by  the  CUBITS  formula  is  greater  than  the  existing 
full  scale  area  of  the  group  (assuming  a design  for  the  group  already  exists) , 
the  full  scale  area  will  be  used  in  the  CONSOLE  plotting  routines.  If  the 
amount  of  space  allocated  to  a functional  group  by  the  CUBITS  formula  is 
less  than  the  existing  full  scale  area  of  the  group,  CONSOLE  will  select  the 
smallest  standard  panel  from  the  STANDARDIZED  PANEL  DATA  section  that  will 
accommodate  the  CUBITS  area  allocated  to  that  group.  With  this  procedure, 
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the  computer-generated  shape  assigned  to  each  functional  group  will  always 
be  user  defined.  Therefore,  CONSOLE  will  avoid  the  problems  encountered  by 
other  area  optimization  routines  that  fail  to  maintain  shape  conservation  as 
areas  are  changed. 

6.5.2  Spatial  Arrangement  of  Functional  Groups 

After  optimizing  the  area  allocated  to  each  functional  group,  the  pro- 
gram flow  will  transfer  to  the  spatial  arrangement  optimization  routines. 

These  routines  simply  consist  of  a set  of  rules  for  processing  the  functional 
groups.  A preliminary  spatial  arrangement  optimization  routine  is  shown  in 
the  flow  diagram  in  Figure  17.  As  can  be  seen,  the  sequence  by  which 
functional  groups  will  be  processed  is  based  upon  several  considerations.  A 
few  of  these  considerations  are  illustrated  by  the  following  questions:  Which 

group  has  the  largest  surface  area?  Was  a mandatory  location  specified  for 
this  group?  Is  this  group  related  to  another  group  that  is  already  on  the 
panel?  Has  a desired  location  been  specified  for  this  group?  As  can  be 
seen  in  Figure  17,  the  processing  rules  can  become  very  complex.  Despite 
their  complexity,  such  logic  diagrams  have  several  advantages.  First,  they 
provide  an  objective  record  of  the  rationale  behind  many  design  decisions. 
Furthermore,  they  are  open  to  examination  and  can  be  easily  modified. 

In  addition  to  the  specific  processing  rules  shown  in  Figure  17,  a small 
number  of  more  general  rules  will  also  be  included  in  the  spatial  arrangement 
optimization  routines.  The  following  examples  illustrate  the  nature  of 
these  rules:  No  group  shall  overlap  a panel  boundary;  all  panels  must  be 

aligned  with  their  supporting  members;  two  panels  cannot  occupy  the  same 
space  on  a panel;  if  no  mandatory  or  desired  location  is  specified  and  the 
group  is  not  related  to  another  group  that  is  already  on  the  panel,  place 
the  group  as  far  forward  (up)  as  possible  and  then  as  close  to  the  center 
of  the  total  CONSOLE  area  as  possible. 

6.6  CONSOLE  Outputs 

CONSOLE  will  produce  both  graphic  and  tabular  outputs.  Tabular  output  will 
include  an  alphabetized  listing  of  all  functional  groups  and  of  all  controls 
and  displays  that  are  contained  in  each  functional  group  and  an  alphabetized 


IS  THIS  GROUP  HIGHtY  YES  WAS  * DESIRED  ZONE  YES  ’ ARE  DOTH  Or  THE  YrS  S1’,*55.!H!L?,S1,!I 

RELATED  TO  EOTH  OF  THE  — SRLCIFIEO  FOR  THIS  — - OTHER  GROUPS  IN  — - tIS?iTZ2^ 

0TH”  W”™  m<WT ™ ««  «»»  Sf  ?he  ot«r  CROUPS 


IS  ONE  OF  THE 
OTHER  CROUPS  IN 
THE  DESIRED  ZONE? 


„ PLACE  THIS  GROUP 
YES  in  THE  C*.  SI  RED  ZONE 
AND  ADJACENT  TO  THC 
RELATED  GROUP 


ARE  BOTH  OF  THE  N0 
OTHER  GROUPS  IN  THE  «— 
SAME  ZONE? 


PLACE  THIS  GROUP 
ADJACENT  TO  THE 
RELATED  GROUP  IN 
THE  HIGHEST 
PRIORITY  ZONE 


IS  THIS  GROUP  MODERATELY 
RELATEO  TO  DOTH  OF  THE 
OTHER  GROUPS 


PLACE  THIS  GROUP 
IN  THAT  ZONE  AND 
ADJACENT  TO  EOT H 
OF  THE  OTHER  GROUPS 


WAS  A DESIRED 
ZONE  SPECIFIED  FOR 
THIS  GROUP? 


APE  BOTH  OF  THE 
RELATED  GROUPS  IN 
THE  DESIRED  ZONE? 


PLACE  THIS  GROUP 
YES  IN  THE  DESIRED  ZONE 
— - AND  ADJACENT  TO 

GOTH  OF  THE  RELATED 
GROUPS 


IS  ONE  OF  THE  OTHER  YES  ^“eSIREo'zCNE 

GROUPS  III  THE  HIGH . ADJACENT  TO  THE 

EST  PRIORITY  ZONE?  reTaUO  GRWP 


PLACE  THIS  GROUP  IN 

GO  TO 

THE  DESIRED  ZONE 

SELECT 

ARE  BOTH  OF  THE 
RELATED  GROUPS  IN 
THE  SAME  ZONE? 


place  This  group 
ADJACENT  TO  THE 
RELATED  GROUP  IN 
THE  HIGHEST 
PRIORITY  ZONE 


PLACE  THIS  GROUP 
IN  THAT  ZONE  AND 
ADJACENT  TO  BOTH 
OF  THE  OTHER  GROUPS 


WAS  A OESIRED  ZONE 
, SPECIFIED  FOR  THIS 
GROUP? 


ARE  BOIH  OF  THE 
RELATED  GROUPS  IN 
THE  SAME  ZONE 


PLACE  THIS  GROUP  IN 
THAT  ZONE  AND 
ADJACENT  TO  BOTH  OF 
THE  RELATED  GROUPS 


IS  ONE  OF  THE 
RELATED  GROUPS  IN 
THE  DESIRED  ZONE? 


PLACE  THIS  GROUP  . 

IN  THE  DESIRED  ZONE 
AND  ADJACFNT  TO  THE 
RELATED  GROUP 


PLACE  THIS  GROUP 
ADJACENT  TO  THE 
RELATED  GROUP  WITH 
THE  HIGHEST 
RELATIONSHIP 


ARE  BOTH  OF  THE 
RELATEO  GROUPS 
in  the  same  zone? 


PLACE  THIS  GROUP 
IN  THAT  ZONE  AND 

AOjAcira  to  r.uTH 

OF  THE  RELATED 
GROUPS 


ACE  THIS  r/niP  ACJ*CINT 
TO  Ti-F.  R'lATiD  GROUP 
WITH  TVf  HIGHEST 
PUATrri  ;r», 


figure  17.  CONSOLE  Spatial  Arrangement  Routine  (cont.) 
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listing  of  all  controls,  displays  and  functional  groups  that  are  contained  in 
each  zone  on  the  panel.  CONSOLE  will  also  provide  a table  that  contains  both 
the  existing  full  scale  surf Ace  area  and  the  CUBITS  generated  raw  score  of  the 
optimized  surface  area  for  all  controls,  displays  and  functional  groups. 
Finally,  an  alphabetized  list  will  be  provided  for  all  controls  and  displays 
that  exceed  a predetermined  CUBITS  raw  score  and  that  have  been  placed  in  a 
low  priority  zone. 


Graphic  outputs  will  be  provided  for  both  an  idealized  and  a pragmatic 
console  layout  design.  Both  layouts  will  clearly  illustrate  the  optimal 
spatial  relationships  between  all  functional  groups.  In  addition,  the 
optimized  panel  space  allocated  to  each  functional  group  will  be  shown  in 
the  idealized  layouts.  Both  the  amount  of  space  allocated  to  a group  and 
it's  location  upon  the  panel  will  be  a direct  result  of  the  user  specified 
parameter  values  that  are  input  to  the  optimization  routines.  As  long  as 
the  values  assigned  to  the  optimization  parameters  remain  the  same,  CONSOLE 
will  continue  to  output  the  same  optimized  layout  design.  A unique  series 
of  optimized  configurations  can  be  produced  by  simply  altering  the  value  of 
one  or  more  of  the  optimization  parameters.  Since  many  different  panel 
configurations  can  be  generated,  the  designer  will  retain  ultimate  responsi- 
bility for  making  design  decisions.  He  will  select  the  most  promising 
layout  for  further  development  and  perform  the  necessary  tradeoffs  to  insure 
that  all  system  requirements  will  be  met.  As  a result  of  these  tradeoffs, 
the  designer  may  decide  to  change  the  size,  shape  or  location  of  several 
controls  and  displays  to  create  the  final  panel  layout. 


7.0  CAFES  VALIDATION  AND  IMPLEMENTATION  PLANS 


A preliminary  plan  for  CAFES  validation  and  implementation  was 
developed  during  the  CAFES  Phase  IV  Program  (Reference  8 ) • The  separate 

implementation  and  validation  plans,  as  they  relate  to  the  Phase  VI  Program, 
will  be  discussed  in  the  following  section. 

7.1  Implementation  Plan 

The  Phase  VI  implementation  plan  will  include  the  following  activities: 

(a)  A phased  delivery  of  all  CAFES  submodels  to  the  NADC  computing 
facility  at  Johnsville,  Pennsylvania  and  the  installation  of 
those  models  on  the  NADC  6600, 

(b)  Verification  tests  to  insure  that  all  of  the  submodel  computing 
functions  are  operating  properly, 

(c)  Presentation  of  a training  course  to  acquaint  NADC  personnel 
with  the  CAFES  submodels, 

(d)  Establishment  of  a CAFES  Center  at  NADC. 

The  first  three  items  are  discussed  in  the  CAFES  Phase  VI  Program  Plan, 
of  this  document. 

Effective  utilization  of  the  CAFES  programs  will  be  contingent  upon  the 
commitment,  by  NADC,  of  dedicated  personnel  to  a Center  for  CAFES  operations. 
The  overall  goal  of  the  proposed  Center  will  be  to  encourage  application  of 
the  CAFES  submodels  to  ongoing  projects  at  NADC.  The  CAFES  Center  should 
be  staffed  by  full  time  personnel  who  are  well  versed  in  CAFES  operations 
including:  input  preparation;  output  interpretation;  system  development 

applications;  availability  of  input  data;  previous  run  history;  current 
stem  -t-i-us;  etc.  The  Center  should  function  as  a self-perpetuating  pro- 
gram ror  training  of  all  potential  NADC  users,  for  consultation  of  individuals 
lacking  expertise  on  CAFES  capabilities,  and  for  performing  all  CAFES  data 
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processing  tasks.  A systematic  procedure  should  also  be  established  for 
maintenance  and  updating  of  the  CAFES  software. 

A full  set  of  user  and  programmer  documentation  will  be  available  at  the 
CAFES  Center.  Additional  documentation  concerning  potential  areas  of 
application  for  CAFES  should  also  be  available.  These  documents  include  the 
Human  Factors  Engineering  Analytic  Process  Definition  and  Criterion  Develop- 
ment for  CAFES  (Reference  6 ) and  CAFES  Applications  in  Ship  Systems 
Development  (Reference  7 ). 

7.2  Validation  Plan 

Since  delivery  and  installation  of  CAFES  is  anticipated  during  the 
Phase  VI  Program,  the  CAFES  submodels  will  be  implemented  before  they  are 
validated.  This  sequence  of  events  is  consistent  with  the  typical  evolution- 
ary development  of  most  computer  programs.  In  fact,  it  is  only  through 
implementation  that  a program  becomes  validated.  Therefore,  the  validation 
concept  will  be  considered  in  the  context  of  CAFES  implementation. 

Specific  plans  for  validation  of  the  FAM  and  the  WAM  submodels  were 
developed  during  the  CAFES  Phase  TV  Program.  In  these  plans,  the  validity 
of  each  submodel  was  to  be  evaluated  in  terms  of  its  fidelity,  or  corres- 
pondence to  the  "real  world"  and  its  utility,  or  contribution  to  the  solution 
of  practical  problems.  During  Phase  VI,  validation  efforts  will  only  be 
directed  toward  an  evaluation  of  the  utility  of  the  CAFES  submodels.  This 
is  not  to  say  that  the  fidelity  concept  is  no  longer  important  but  that  it  is 
more  important  to  establish  the  utility  of  a model  before  examining  its  fidel- 
ity. If  it  is  found  that  a model  does  not  contribute  to  the  solution  of 
practical  problems,  it  does  not  matter  whether  the  model  corresponds  to  the 
"real  world"  or  not.  Thus,  only  after  establishing  the  utility  of  a model 
does  it  become  necessary  to  evaluate  the  fidelity  of  the  model. 

Data  relevant  to  the  utility  question  will  be  obtained  by  trial 
applications  of  the  CAFES  submodels  to  practical  problems.  Possible 
sources  of  application  include  ongoing  system  development  projects  and 
programs  where  long  range  forecasting  of  requirements  are  being  made 
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8.0  RESTRUCTURE  OF  CAFES  DOCUMENTATION 


The  CAFES  User's  Guide  has  been  under  evolutionary  development  since 
the  completion  of  Phase  IB  in  1972.  During  this  time,  both  user  and  pro- 
grammer documentation  were  developing  rapidly  to  keep  pace  with  new  soft- 
ware developments.  The  size  and  the  complexity  of  the  user  documentation 
has  continued  to  increase  with  each  new  developmental  phase.  As  a result  of 
these  changes,  retrieval  of  information  from  the  CAFES  documents  has  become 
increasingly  difficult.  This  problem  has  arisen  because  most  of  the  CAFES 
submodel  programs  have  spanned  several  developmental  phases.  Thus,  infor- 
mation on  a particular  model  may  be  found  in  several  different  CAFES  documents. 

Initial  efforts  were  made,  during  Phase  IV,  to  improve  the  user  interface 
by  eliminating  the  demand  for  extensive  cross  referencing  to  information  con- 
tained in  preceding  CAFES  documents.  To  accomplish  this,  a detailed  summary 
for  each  of  the  CAFES  submodels  was  prepared  by  selecting  material  from  the 
preceding  developmental  phases.  Specific  information  about  subsystem  concept 
definitions,  design  features  and  operations,  inputs,  outputs  and  applications 
was  integrated  within  each  submodel  summary.  Restructuring  of  documentation 
continued  during  Phase  V in  anticipation  of  submodel  delivery  and  installation 
during  the  Phase  VI  Program. 

The  previous  efforts  to  modularize  and  integrate  the  CAFES  documentation 
will  be  extended  by  the  creation  of  a separate  User's  Manual  and  a Programmer's 
Manual  for  each  of  the  CAFES  submodels.  A preliminary  organizational  scheme 
for  these  manuals  was  developed  and  information  from  previous  CAFES  volumes 
relevant  to  the  current  organizational  structure  is  being  retrieved  and  up- 
dated. These  manuals  have  been  retained  due  to  the  tentative  nature  of  their 
structure  and  to  the  continuing  requirement  for  selective  modification  of  the 
contents.  However,  copies  of  the  manuals  could  be  made  available  upon  request. 

The  eventual  plan  for  CAFES  documentation  is  to  produce  a multi-volume  set  of 
documents.  The  complete  set  of  documents  will  contain  an  executive  level  sum- 
mary of  the  CAFES  System,  a general  introduction  to  the  CAFES  System  and  a 
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detailed  description  of  each  of  the  CAFES  submodels.  The  introductory  vol- 
ume will  contain  a top  level  discussion  of  the  general  requirements  and  sys- 
tem specifications  for  CAFES,  a summary  of  the  overall  CAFES  concept  and 
a brief  description  of  each  of  the  CAFES  submodels.  A User's  Manual  and  a 
Programmer's  Manual  will  be  prepared  for  the  DMS , FAM,  WAM,  CAD,  and  the 
CAFES  interface  modules.  (Format  for  the  HOS  documentation  will  be  coordi- 
nated with  Analytics  Inc.).  These  volumes  will  include  all  of  the  detailed  inf or 
mation  required  to  understand  and  use  the  submodels. 

The  user  documentation  will  include  a discussion  of  the  following  items: 

(a)  the  purpose  of  the  model, 

(b)  appropriate  problems  for  model  application, 

(c)  how  the  model  operates, 

(d)  all  model  inputs  and  outputs, 

(e)  sample  data  cases  with  interpretation  of  outputs, 

(f)  options  of  the  model, 

(g)  a complete  listing  and  explanation  of  all  program-generated  messages. 
The  programmer  documentation  will  include  a description  of  the  following  items: 

(a)  the  scope  and  purpose  of  the  model, 

(b)  computing  system  specifications  (type  of  computer,  operating 
system,  compiler,  peripherals), 

(c)  gross  operational  characteristics  of  the  model  (run  times,  core 
requirements) , 

(d)  the  structure,  functional  flow,  data  files  and  data  flow  of  the  model, 

(e)  use  of  COMMON  storage. 


(f)  the  special  purpose,  diagnostics,  change  procedures  and  testing  for 
all  subprograms  of  the  model, 

(g)  listings  of  the  source  code  for  the  model, 

(h)  an  alphabetized  glossary  of  all  programming  variables. 

The  introductory  volume  and  each  of  the  submodel  volumes  will  be  issued 
in  the  form  of  a three-ring  binder  to  facilitate  updating  of  the  CAFES 
documentation  as  the  models  are  modified  in  future  developmental  phases. 

The  final  documentation  system  is  illustrated  in  Figure  18. 

A concise  Document  Information  Guide  was  also  developed  during  Phase  V 
to  assist  in  the  restructuring  task  and  to  relieve  the  information  retrieval 
problem.  The  Guide  indexes  and  cross  references  most  of  the  information 
contained  in  the  previous  CAFES  volumes.  The  Document  Information  Guide  is 
contained  in  appendix  H. 
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9.0  CAFES  INTEGRATION  PLAN 


The  primary  goal  of  the  CAFES  integration  plan  is  to  integrate  CGF,  and 
HOS  into  the  CAFES  system.  These  models  are  being  emphasized  for  two 
reasons.  First,  neither  CGE  nor  HOS  was  developed  under  the  CAFES  Program. 

CGE  was  developed  by  The  Boeing  Company  during  the  period  1967  - 1971  while 
under  contract  to  JANAIR.  HOS  is  currently  being  developed  by  NADC.  Secondly, 
all  three  of  the  computer  systems  would  benefit  by  an  active  data  exchange 
program.  The  CAFES  submodels  could  provide  CGE  and  HOS  with  required  input 
data  while  CGE  and  HOS  could  be  of  value  to  CAFES  by  reflecting  errors  that 
may  have  been  made  in  earlier  stages  of  the  system  development  cycle. 

The  initial  efforts  to  integrate  CGE  into  CAFES  were  begun  during  Phase 
IV  of  the  CAFES  Program  and  have  continued  during  Phase  V.  The  integration 
effort  began  with  an  examination  of  CGE  inputs,  outputs  and  processes  to 
identify  all  potential  data  interfaces  with  the  other  CAFES  models.  Several 
data  interfaces  were  identified  and  are  summarized  below. 


INTERFACE  NO.  1 


CGE 


Crewstation 

Geometry 


CAD 


Explanation:  Crewstation  geometry  which  has  been  input  to  CGE  could  be  input 

directly  to  CAD  from  CGE  for  reach  analysis,  vision  analysis,  escape 
analysis,  or  for  redesign  purposes. 


INTERFACE  NO.  2 


DMS 


Crewstation  Geometry 
Task  Sequence  Data 


CGE 


Explanation:  The  free  field  format  of  CAFES  could  be  used  to  input  and 

store  cockpit  plane  and  control  definitions  and  task  sequence  data  in  the 
DMS.  Upon  user  command,  a card  deck  containing  the  same  data  could  be  pro- 
duced with  a format  identical  to  the  inputs  required  by  the  CGE  CDDATA  and 
STORAGE  models. 
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INTERFACE  NO.  3 


Crewstation 

Geometry 


Explanation:  Crewstation  designs  developed  by  CAD  could  be  input  directly 

to  CGE  to  evaluate  them  for  physical  and  visual  interferences,  compliance  with 
military  specifications  and  standards,  or  to  generate  perspective  or 
sectional  drawings  of  the  crewstation. 


INTERFACE  NO.  4 


Reach 

Envelopes 


Explanation:  Reach  envelopes  for  various  sized  crewmembers  and  different 

seat  positions  generated  by  the  CGE  Reach  Basket  Model  could  be  input  directly 
to  CAD  for  crewstation  reach  analyses. 


INTERFACE  No.  5 


Escape 

Envelopes 


Explanation:  Escape  envelopes  for  various  sized  crewmembers,  seat  back 

angles  and  seat  positions  generated  by  CGE  could  be  input  directly  to  CAD 
for  escape  analyses. 


INTERFACE  No.  6 


Task 

Sequence  Data 


Explanation:  Task  sequences  verified  by  WAM  workload  analyses  could  be 

directly  input  to  CGE  for  motion  interference  analysis. 


Three  of  these  interfaces  have  already  been  developed.  The  first  interface 
was  developed  during  the  CAFES  Phase  IV  Program.  The  second  and  third  inter- 
faces were  developed  during  Phase  V and  are  described  in  this  document. 
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Several  changes  to  the  DMS  and  to  the  CGE  software  were  required  to  make 
CGE  compatible  with  the  CAFES  Data  Management  System.  These  changes  included 
the  creation  of  new  primary  and  secondary  data  categories  within  the  DMS 
to  receive  input  data  required  by  CGE  and  the  development  of  buffer  routines 
for  conversion  of  CAFES  submodel  data  parameters  into  a format  that  would 
be  consistent  with  CGE  input  requirements. 

Integration  of  HOS  into  the  CAFES  system  was  begun  during  Phase  V of 
the  CAFES  Program.  The  HOS  integration  effort  began  with  a series  of 
meetings  which  were  held  at  the  Boeing  Aerospace  Company  to  consider  possible 
interfaces  between  the  Human  Operator  Simulator  and  the  other  CAFES  submodels. 
Representatives  from  the  Naval  Air  Development  Center,  Analytics  Incorporated , 
Boeing  Aerospace  Company  and  Boeing  Computer  Services  participated  in  the 
discussions.  It  was  concluded  that  the  integrated  CAFES  system  will 
generally  be  applied  in  two  different  problem  areas;  development  of  new 
systems  and  reevaluation  of  existing  systems.  For  new  systems  development 
programs,  the  CAFES  submodels  will  generally  be  applied  in  the  following 
order:  FAM;  WAM;  CAD;  CGE  and  HOS.  This  order  corresponds  to  the  sequence 

of  efforts  normally  performed  by  the  HFE  in  new  systems  development  pro- 
grams. The  system  development  cycle  begins  with  a definition  of  mission 
requirements  and  progresses  through  the  following  stages:  function  alloca- 

tion; task-workload  analysis  and  finally,  crewstation  design  and  evaluation. 
Hence,  a unidirectional  forward  feeding  interface  is  implied  in  which  data 
obtained  from  earlier  developmental  phases  will  be  input,  or  will  facilitate 
input,  to  later  developmental  phases. 

The  CAFES  submodels  will  also  be  used  to  evaluate  existing  systems.  Such 
applications  might  include  the  evaluation  of  alternative  cockpit  configurations 
or  an  evaluation  of  the  impact  on  workload  due  to  the  addition  of  a new 
piece  of  equipment  in  a proven  configuration.  For  these  types  of  problems, 
the  CAFES  submodels  will  probably  be  used  more  or  less  independently.  The 
selection  of  appropriate  CAFES  submodels  will  depend  upon  the  following 
factors:  how  quickly  an  answer  is  needed;  the  degree  of  accuracy  required 

and  the  amount  of  detailed  information  available  for  the  system  being 
examined.  CGE  and  HOS  would  most  likely  be  used  when  a great  deal  of 


accruacy  is  required,  when  HFE  decision  time  is  not  necessarily  a critical 
factor  and  when  detailed  information  about  the  system  is  available.  FAM, 

WAM  and  CAD  would  be  applied  when  the  amount  of  detailed  information  and/or 
decision  time  is  quite  small  or  when  a less  sophisticated  evaluation  is  ade- 
quate and  the  intent  is  to  quickly  identify  and  resolve  gross  problem  areas 
before  concepts  are  evolved  to  any  large  degree. 

Given  these  constraints  on  the  probable  use  of  the  CAFES  submodels,  the 
following  interface  modules  were  identified  for  possible  future  development. 


INTERFACE  NO.  7 


FAM 


Operator 
Procedures  Data 


Explanation:  The  Human  Operator  Procedures  Language  (HOPROC)  could  be  used 

to  describe  all  of  the  tasks  in  the  task  list  from  a FAM  mission  scenario. 

FAM  would  then  produce  a task  timeline  for  each  operator  over  the  entire  mis- 
sion. The  task  timeline  would  be  composed  of  operator  procedure  statements 
that  could  be  used  by  WAM  for  workload  evaluations  and  could  also  be  augmented 
with  additional  HOPROC  statements  to  provide  the  Operator  Procedures  input  re- 
quired by  the  HOPROC  Assembler  Loader  (HAL) . The  basic  advantage  of  this 
interface  is  that  the  task  timeline  provided  by  FAM  would  be  based  upon  task 
reliability  data.  Thus,  task  reliability  data  would  be  indirectly  incorporated 
into  HOS. 


A second  benefit  of  the  FAM/HAL  interface  is  that  the  CAFES  models  could 
take  advantage  of  the  high  degree  of  precision  and  consistency  of  terminology 
that  is  inherent  in  the  HOPROC  language.  The  word,  task,  for  example,  has 
been  used  rather  freely  in  the  CAFES  documentation.  Inconsistencies  in  the 
level  of  detail  used  to  describe  a task  sequence  soon  become  apparent  when  the 
work,  task,  is  equated  with  such  activities  as  grasping  a control  (micro- 
molecular  level),  changing  a control  setting  (molecular  level)  and  performing 
a series  of  turning  maneuvers  (molar  level) . Such  a cavalier  use  of  terms  is 
cour  erproductive  to  the  stated  goals  of  CAFES.  The  standardization  of  termi- 
nology gained  from  the  HOPROC  language  would  also  enable  the  CAFES  user  to 
prepare  input  data  more  rapidly  and  to  track  the  data  more  easily  from  one 
model  to  another. 
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INTERFACE  NO.  8 


Control,  Display 
and  Setting  Data 


Explanation:  An  interface  could  be  developed  between  CAD  and  HAL  that 

would  generate  input  data  for  the  DISPLAY,  CONTROL  and  SETTING  sections 
required  by  HAL.  These  sections  contain  information  such  as  the  title  and 
type  of  each  device,  scale  factors,  scale  settings  and  device  coordinates. 
This  information  could  be  placed  in  the  CAD  data  bank  during  the  data 
digitization  process.  The  basic  advantage  provided  by  the  CAD  data  bank 
is  that  a built-in  cross-referencing  system  is  thereby  created  between  the 
aircraft  coordinate  system  and  the  information  contained  in  the  DISPLAY, 
CONTROL  and  SETTING  sections.  With  this  interface,  it  would  be  possible  to 
obtain  panel  plots  and  tabular  listings  showing  all  devices  and  their 
associated  characteristics  for  each  panel.  Thus,  this  interface  could  be 
used  to  perform  data  verification  and  checkout  of  HAL  input  data. 


INTERFACE  NO.  9 


Crewstation 

Coordinates 


Explanat ion:  A data  digitizing  capability  could  be  developed  to  provide 

the  three-dimensional  coordinates  for  all  individual  controls,  displays 
and  symbols  as  well  as  overall  crewstation  layouts  that  are  required  as 
direct  inputs  to  HOS.  The  CAD  submodel  could  transform  the  digitized  data 
for  individual  controls,  displays  and  symbols  into  an  appropriate  coordinate 
system  and  output  the  coordinates  to  a permanent  file.  The  data  on  this 
file  would  contain  blank  fields  in  locations  that  require  unique  inputs  to 
HOS  (i.e.,  device  model  number,  hab  strength,  criticality,  etc.).  This  file 
could  be  merged  with  a similar  file  containing  the  unique  HOS  inputs.  The 
merged  file  could  then  be  input  directly  to  HOS.  The  advantage  of  this  inter- 
face is  that  the  user  would  not  be  required  to  manually  obtain,  code  and 
keypunch  the  three-dimensional  coordinates  required  by  HOS. 

Despite  the  unidirectional  nature  of  the  HOS/CAFES  interfaces  identified 
above,  it  should  be  noted  that  outputs  from  HOS  will  be  useful  to  the  CAFES 
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submodels  in  at  least  two  respects.  First,  HOS  can  be  used  to  generate 
performance  times  of  specific  tasks  for  which  empirical  data  are  not 
available.  The  HOS  generated  performance  times  could  then  be  used  in 
future  FAM  and  WAM  analyses  involving  those  tasks.  Secondly,  workload 
problems  revealed  by  HOS  outputs  will  lead  to  modification  of  the  basic 
function  allocation  and/or  crewstation  design  assumptions  that  were  made  in 
earlier  phases  of  the  system  development  cycle. 


’I 


The  final  suggestion  for  a HOS/CAFES  interface  deals  with  a need  for 
consistency  of  terminology  in  the  sample  problem  documentation  for  all 
of  the  CAFES  submodels.  This  need  could  be  satisfied,  to  a large  extent, 

1*  by  the  selection  of  a standard  problem  for  analysis.  Such  a problem  would 

help  an  unfamiliar  user  understand  the  relationship  between  the  inputs 
required  by  the  different  submodels.  This  type  of  integration  effort  would 
also  facilitate  interpretation  and  application  of  submodel  outputs  by 
allowing  the  user  to  readily  compare  and  correlate  the  inputs  and  outputs 
of  one  submodel  with  the  inputs  and  outputs  of  another  submodel. 


112 


10.0  CAFES  PHASE  VI  PROGRAM  PLAN 


Most  of  the  CAFES  effort  during  the  past  five  phases  has  been  directed 
toward  concept  formulation  and  software  development  of  a number  of  computer- 
aids  for  the  HFE  community.  Until  now,  each  of  the  CAFES  computer  models 
has  been  primarily  used  in  a research  and  development  environment.  During 
the  Phase  VI  Program,  however,  major  emphasis  will  shift  from  software 
development  to  software  refinement  and  documentation  in  anticipation  of 
routine  production  runs  following  delivery  and  installation  at  NADC.  The 
successful  transition  from  a research  and  development  level  to  a production 
level  is  contingent  upon  completion  of  the  following  tasks: 

(a)  Complete  Submodel  Integration, 

(b)  Complete  Submodel  Efficiency  Improvements, 

(c)  Complete  User  Interface  Improvements, 

(d)  Complete  System  Documentation, 

(e)  Complete  CAD  Developments, 

(f)  Prepare  CAFES  Training  Course  Materials, 

(g)  Establish  Configuration  Control  System  and  Procedures, 

(h)  Deliver  and  Install  CAFES  at  NADC. 

Each  of  these  tasks  will  be  discussed  in  the  following  paragraphs. 

j 

10.1  Complete  Submodel  Integration 

Integration  of  the  CAFES  submodels  will  require  work  in  two  areas.  The 
first  area  involves  the  development  of  interface  modules  between  the  CAFES 
submodels.  As  noted  in  the  CAFES  Interface  Plan  of  this  document,  the  primary 
goal  of  the  integration  effort  will  be  to  develop  several  interface  modules 
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between  CGE  and  the  CAFES  submodels  and  between  HOS  and  the  CAFES  submodels. 

The  specific  interface  modules  to  be  developed  are  discussed  in  the  CAFES 
Interface  Plan. 

The  second  integration  area  involves  the  identification  of  all  direct  data 
interfaces  between  the  CAFES  submodels.  Two  types  of  data  interfaces  will  be 
defined:  direct  and  indirect.  A direct  data  interface  will  refer  to  an 

exchange  of  data  between  models  that  does  not  require  u9er  intervention.  In 
an  indirect  data  interface,  the  user  will  mediate  the  data  exchange  by 
using  outputs  of  one  model  to  guide  his  judgment  in  preparing  inputs  to 
another  model.  Specific  data  interfaces  for  FAM,  WAM  and  CAD  were  identified 
during  Phase  IV.  This  effort  will  be  extended  to  include  the  DMS,  the 
CAFES/CGE  interface  modules  and  the  CAFES/HOS  interface  modules. 

10.2  Complete  Submodel  Efficiency  Improvements 

Several  tasks  are  included  under  the  category  of  submodel  efficiency 
improvements.  Perhaps  the  most  important  task  will  be  program  debugging  as 
the  models  undergo  final  verification  testing.  A greater  number  of  verifi- 
cation tests  will  be  required  for  the  FAM  and  CAD  submodels  since  they  have 
been  executed  less  frequently  than  the  WAM.  In  addition,  minor  software 
improvements  will  be  made  to  enhance  specific  model  capabilities  as  blocks  of 
inefficient  coding  are  discovered.  Two  such  areas  for  improving  specific 
model  capabilities  have  already  been  identified  for  the  DMS.  First,  the 
total  compilation  time  required  to  remove  data  input  errors  could  be  reduced 
if  the  user  were  allowed  to  discover  many  data  input  errors  in  a single  job 
submittal.  This  could  be  achieved  by  modifying  the  CAFES  executive  and 
data  editors  so  that  they  would  be  able  to  recognize  a valid  input  statement 
that  immediately  follows  an  invalid  statement.  With  this  modification,  program 
compilation  would  continue  following  improper  data  input  and  would  expose  a 
greater  number  of  errors  in  the  input  data. 

A second  DMS  efficiency  improvement  could  be  obtained  by  preventing 
erroneous  input  data  from  being  executed.  Only  after  all  errors  in  the 
compilation  phase  are  discovered  and  corrected  should  program  execution  be 
allowed  to  continue.  Therefore,  the  overall  efficiency  of  the  CAFES  submodels 
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could  be  improved  if  the  DMS  executive  was  modified  to  preclude  program 
execution  following  a data  input  error. 

Additional  software  improvements  have  been  identified  for  the  CGE 
Reach  Basket  Model.  A discussion  of  these  efficiency  improvements  is  con- 
tained in  this  document. 

10.3  Complete  User  Interface  Improvements 

The  user  interface  is  directly  affected  by  such  factors  as  the  prepara- 
tion of  data  inputs,  interpretation  of  data  outputs  and  the  amount  and  kind 
of  error  diagnostics  that  are  provided.  During  earlier  CAFFS  Phases,  major 
emphasis  was  placed  upon  concept  formulation  and  software  development  with 
relatively  little  attention  toward  optimization  of  the  user  interface. 

Hence,  transition  of  the  CAFES  models  to  a production  level  system  will 
require  a large  number  of  user  interface  refinements. 

One  set  of  refinements  will  involve  modification  of  the  CAFES  data 
editors.  When  a data  input  error  is  recognized  by  the  CAFES  data  editors, 
the  error  is  flagged  with  an  error  number  on  the  user's  output.  The  us£r 
must  then  determine  the  meaning  of  the  error  number  by  referencing  a table 
of  error  messages.  Timely  interpretation  of  data  input  errors  would  be 
enhanced  by  storing  all  error  descriptions  in  the  DMS  data  bank.  The  CAFES 
error  diagnostic  software  could  then  be  modified  to  provide  the  following 
information  each  time  a data  input  error  is  encountered:  the  error  number, 

the  current  value  of  all  relevant  variables  and  an  English  language  descrip- 
tion of  the  error. 

A second  set  of  user  interface  refinements  will  be  directed  toward  im- 
proving the  interpretation  of  CAFES  outputs.  At  the  present  time,  many  of 
the  submodel  output  reports  are  quite  cluttered  and  require  extensive  user 
familiarity  for  interpretation.  This  is  especially  true  for  many  of  the 
FAM  and  CAD  output  reports.  The  interpretation  of  model  outputs  can  be 
significantly  improved,  in  most  cases,  by  a reorganization  of  tabular  out- 
puts and  by  a judicious  selection  of  data  parameter  names.  These  changes 
will  be  accomplished  through  the  selective  modification  of  software  routines 
in  the  DMS  report  generator  and  of  parameter  names  in  the  submodel  data 
categories. 
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10.4  Complete  System  Documentation 


Both  the  user  interface  and  the  programmer  interface  with  the  CAFES 
submodels  will  be  significantly  improved  by  completion  of  the  CAFES  User's 
Guide  and  Programmer's  Guide.  These  volumes  will  contain  extensive  documen- 
tation concerning  the  scope  of  each  model,  potential  areas  of  application, 
model  assumptions,  sample  data  cases,  input  requirements,  output  formats  and 
an  explanation  of  the  user's  role  in  CAFES  applications.  Documentation  will 
also  be  included  for  all  new  model  developments,  submodel  integration  and 
submodel  efficiency  improvements  that  are  completed  during  the  Phase  VI 
Program.  Further  information  concerning  the  CAFES  System  documentation  can 
be  found  in  the  RESTRUCTURE  OF  CAFES  DOCUMENTATION  section  of  this  document. 

10.5  Complete  CAD  Developments 

Completion  of  all  CAD  submodel  developments  will  require  work  in  four 
basic  areas.  First  a number  of  tasks  must  be  performed  to  refine  the  CAD 
capabilities  that  were  initiated  in  Phases  III  and  IV.  The  following  tasks  are 
included  in  this  category: 

(a)  Develop  the  capability  for  the  cockpit  scaling  subroutine  to 
perform  differential  scaling  of  cockpit  geometry.  At  the  present 
time,  only  uniform  scaling  of  cockpit  geometry  can  be  performed, 

(b)  Develop  the  capability  for  production  of  Calcomp  3-view  plots  that 
will  provide  front  view,  top  view,  side  view  and  axonometric 
views  of  crewstation  geometry, 

(c)  Develop  the  capability  for  user  specification  of  the  scale  factor 
for  output  of  panel  plots, 

(d ) Modify  the  crewstation  tailoring  module  to  provide  for  easier 
crewstation  geometry  updates. 

: hi  second  set  of  CAD  development  tasks  will  focus  upon  the  CAD  reach 
analysis  nodule.  In  the  current  reach  analysis  module,  a laborious  manual 
procedure  is  required  to  prepare  the  reach  analysis  input  data.  Useability  of 


the  reach  analysis  module  would  be  greatly  increased  if  the  reach  envelope 
data  were  automatically  generated  and  input  to  the  CAD  reach  analysis  module. 
This  refinement  will  require  a trade  study  and  the  development  of  a new  CAFES 
interface  module.  The  trade  study  will  be  performed  to  evaluate  the  relative 
merits  of  using  the  CGE  Reach  Basket  Analysis  versus  the  Crewstation  Assessment 
of  Reach  (CAR)  Model  to  generate  reach  envelopes  that  can  be  input  directly  to 
CAD.  Based  upon  the  outcome  of  the  trade  study,  an  interface  module  will  be 
developed  to  allow  for  input  of  reach  envelopes  to  the  reach  analysis  module. 

The  third  set  of  tasks  will  continue  development  of  CONSOLE,  the 
optimized  panel  space  allocation  program.  Design  guidelines  and  general 
functional  requirements  for  CONSOLE  were  developed  during  Phase  V and  are 
contained  in  this  document.  The  detailed  software  design  and  software 
development  tasks  will  be  performed  during  Phase  VI.  These  tasks  will 
include  flow  charting,  coding  and  software  verification  for  the  preliminary 
CONSOLE  specification. 

The  final  CAD  objective  will  be  to  develop  a stand  alone  data  digitizing 
program  and  to  incorporate  that  program  into  the  CAD  editor.  With  this 
program,  digitized  data  could  be  stored  on  a tape  or  disk  file  and  auto- 
matically accessed  by  CAD  for  execution  of  the  CAD  subprograms.  Several 
advantages  of  the  data  digitizing  procedure  were  demonstrated  during  Phase 
IV.  The  data  digitizer,  when  combined  with  a computer  terminal  that  will 
allow  interpolation  of  alphabetic  characters  within  a string  of  numeric 
characters,  was  found  to  be  a versatile  tool,  with  its  speed  and  accuracy  far 
exceeding  that  obtainable  by  manual  methods. 

10.6  Prepare  CAFES  Training  Materials 

A training  course  on  CAFES  operations  will  be  presented  to  NADC  per- 
sonnel following  installation  of  CAFES  at  NADC.  Development  of  the  training 
course  will  entail  preparation  of  instructional  materials,  visual  aids  and 
sample  problem  exercises.  The  training  course  will  include  classroom  problem 
solving  experience  via  preparation  of  data  input  cases,  execution  of  the 
CAFES  submodels  and  interpretation  of  model  outputs. 
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10.7  Prepare  Softward  Delivery  Package 

Preparation  of  the  NADC  software  delivery  package  will  be  coordinated 
with  personnel  from  NADC  and  from  SAMA  Division-Eastern  Operations  in 
Falls  Church,  Virginia.  Specific  tasks  will  include: 

(a)  Definition  of  computer  systems  at  BCS  and  NADC, 

(b)  Definition  of  a baseline  source  code  configuration  and  an 
implementation  subset, 

(c)  Development  of  a benchmark  data  set  containing  cases  to  com- 
prehensively test  the  code, 

(d)  Establishment  of  an  implementation  software  configuration  at 
SAMA  Division  Eastern  Headquarters/NADC , 

(e)  Execution  of  the  implementation  code  against  the  benchmark  data 
set. 

10.8  Establish  Configuration  Control  System  and  Procedures 

A configuration  control  system  and  a set  of  configuration  control 
procedures  must  be  established  prior  to  delivery  and  installation  of  CAFES 
software.  The  configuration  control  system  and  procedures  will  provide  a 
systematic  method  by  which  to  maintain  and  update  the  NADC  CAFES  configura- 
tion. Thus,  the  system  will  provide  for  technical  consultation  and  software 
maintenance  related  to  operation  and  use  of  the  NADC  configuration  and,  at 
the  same  time,  allow  for  new  CAFES  developments  and  modifications  to  existing 
software  routines  without  interrupting  CAFES  operations  at  NADC. 

10.9  Deliver  and  Install  CAFES  at  NADC 

Delivery  and  installation  of  the  CAFES  software  will  be  coordinated  with 
NADC  personnel  and  with  SAMA  Division-Eastern  Operations  personnel.  The 
installation  procedure  will  involve  loading  each  of  the  CAFES  submodels  into 
the  NADC  0 00  and  verification  that  all  of  the  computing  routines  execute 
properly. 
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APPENDIX  A:  MILSTAN  FIXED  WING  ADDED  TESTS  ANALYSIS 


Page  No.*  Test  No. 


Coded  Test  Procedure 


XI1-63 

1 

2 

XII-69 

3 

A 

5 

XII-92 

6 

XII-93 

7 

XII-96 

8 

XI 1-99 

9 

10 

XII-105 

11 

XII-107 

12 

13 


XII-L08  1A 

15 


Distance  of  LRUDPDCL/RRUPDPDCL  left/right  DEP 

Test  distance  of  ALLPAN,  ALLCP  from  (new)  foot  volume 

planes  using  AND  connectors 

Distance  of  DEP  above  DEP2 

Distance  of  DEP  from  DEP2 

Distance  of  composite  SEATPAN  from  (new)  left  limit  plane 
for  copilot  seat 

Distance  of  composite  INSTRPAN  from  (new)  landing  gear 

position  indicator  centroid  LDGGPICP 

also 

distance  of  LDGGDN,  LDGGUP  from  centroid 
Distance  of  composite  CSGPAN  from  NSWHLSTG 
Distance  of  POWLEVCP  from  TURBRVTH 
Distance  of  FUELCR  and/or  FLSYSLCR  from  BSTPMP 
Distance  of  composite  POWER  from  FUELCR 

Distance  of  composite  POWER  from  (new)  manual  sight  range 
point  MANSIR 

Distance  of  composite  RADIOCR  forward  of  RAEBSTCT 
also 

Distance  of  RAEBSTCT  from  composite  CONSOLE 
Distance  of  AFCCP  from  composite  CONSOLE 
also 

Distance  of  composite  POWER  forward  of  AFCCP 
Distance  of  composite  POWER  aft  of  LDGGDN 
Distance  of  composite  CONSOLE  from  LDFLPCR 
also 

Distance  of  composite  POWER  forward  of  LDFLPCR 


*Page  numbers  refer  to  Appendix  XII  of  Document  D162-10127-3,  Cockpit  Geometry 
Evaluation  Final  Report  (Phase  III),  Vol.  Ill-Computer  Program,  Sept.  1972. 


APPENDIX  A:  MILSTAN  FIXED-WING  ADDED  TESTS  ANALYSIS  (cont.) 


Page  No. 


XII-110 


XII-111 


Test  No. 


Coded  Test  Procedure 


16 

Distance 

of 

also 

Distance 

of 

17 

Distance 

of 

18 

Distance 

of 

also 

Distance 

of 

and 

Distance 

of 

19 

Distance 

of 

also 

Distance 

of 

20 

Distance 

of 

also 

Distance 

of 

also 

Distance 

of 

21 

Distance 

of 

22 

Distance 

of 

23 

Distance 

of 

also 

Distance 

of 

24 

Distance 

of 

25 

Distance 

of 

and 

Distance 

of 

also 

Distance 

of 

and 

Distance 

of 

and 

Distance 

of 

composite  CONSOLE  from  WGFLDCR 

composite  POWER  forward  of  WGFLDCR 
composite  POWER  from  EMGCYBR 
CANJETSC  forward  of  DEP 


(new)  overhead  panels  composite  from  CANJETSC 

composite  EMPAN  from  CANJETSC 
DRGCHHN  right  of  POWQUACP 

DRGCHHN  from  POWQUACP 
DRGCHSW  right  of  POWQUACP 

DRGCHHN  from  POWQUACP 

DRGCHSW  aft  of  POWQUACP 
composite  CONSOLE  from  POWQUACP 
TURBRVTH  from  POWQUACP 
composite  CONSOLE  from  SUPCHGR 

composite  POWER  forward  of  SUPCHGR 

(new)  overhead  panels  composite  from  COOLCR 

composite  CONSOLE  from  FLSYSLCR 

composite  POWER  forward  of  FLSYSLCR 

(new)  overhead  panels  composite  from  FLSYSLCR 

FLSYSLCR  right  of  DEP 

FLSYSLCR  left  of  DEP 2 
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Page  No.  Test  No. 


Coded  Test  Procedure 


XII-112 


XII-114 


XII-115 


26 


27 


28 


29 


30 


31 


32 


33 

34 

35 


Distance  of  AIRSTSW  from  POWQUACP 
also 

Distance  of  AIRSTSW  aft  of  POWQUACP 
also 

Distance  of  (new)  overhead  panels  composite  from  AIRSTSW 
Distance  of  FEATHER  forward  of  DEP 
also 

Distance  of  FEATHER  above  DEP 
Distance  of  composite  CONSOLE  from  RAMAIRTB 
also 

Distance  of  composite  POWER  forward  of  RAMAIRTB 
Distance  of  composite  POWER  forward  of  VCOMMHF 
also 

Distance  of  composite  CONSOLE  from  VCOMMHF 
Distance  of  composite  CONSOLE  from  NAVCR 
also 

Distance  of  composite  POWER  forward  of  NAVCR 
Distance  of  composite  CONSOLE  from  IFFSIF 
also 

Distance  of  NAVCR  from  IFFSIF 
Distance  of  OXYGEN  forward  of  DEP 
also 

Distance  of  OXYGEN  left  of  DEP 

Same  tests  for  0XYGEN2  versus  DEP2,  except  that  distance 
right  of  DEP2  is  tested. 

Distance  of  CMPQDSCN  from  OBSTPAN  panel.  Same  test  for 
CMPQDSC2  versus  0BSTPAN2 

Distance  of  AGSUITCR  from  OBSTPAN  panel.  Same  test  for 
AGSUITC2  versus  0BSTPAN2 

Distance  of  SHHARNLK  from  OBSTPAN  panel  and  forward  of  DEP. 
Same  tests  for  SHHARNL2  versus  0BSTPAU2  and  DEP2. 
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APPENDIX  A:  MILSTAN  FIXED-WING  ADDED  TESTS  ANALYSIS  (cont.) 


Page  No. 

Test  No. 

Coded  Test  Procedure 

36 

Distance  of  SEATADJ  from  IBSTPAN  panel  and  distance  below 
NUTRLSRP.  Same  test  for  SEATADJ2  versus  IBSTPAN2  and  NUTRLSR2 

XII-116 

37 

Distance  of  composite  LCONSOLE  from  MAPSTOW.  Same  test 
for  composite  RCONSOLE  versus  MAPSTOW2 

38 

Distance  of  OVHDPAN  composite  from  AIPITHT 

XII-175 

39 

Distance  of  VTSTADJ  from  IBSTPAN  panel 
Distance  of  VTSTADJ2  from  0BSTPAN2  panel 

XI 1-189 

40 

Test  not  cost-effective  using  present  program  capability 

41 

Same  as  40 

42 

Same  as  40 

43 

Angle  of  LPSTPAT  with  DEPZCP 

44 

Distance  of  IBSTPAN  and  OBSTPAN  from  NUTRLSRP 

45 

Included  comment  for  this  test  stating  the  requirement 

46 

Same  as  for  45 

47 

Same  as  for  45 

48 

Same  as  for  45 

49 

Angle  of  CSBTP  with  DEPYCP 

50 

Angle  of  CSCTP  with  DEPZCP 

XII-227 

51 

Angle  of  RRUDPDL  and  LRUDPDL  with  DEPZCP.  Note  heel  support 

requirement  as  a comment. 


MIL-STD-203E 


ably  designed  so  that  a separate  and  dis- 
tinct action  Is  required  to  place  switch  in 
MANUAL  position. 


VECTOR 

BOEMAN  GEOMETRY 


MIL-STD-203E 


of  and  on  same  axis  as  the 
power  controls 


MIL-STD-203E 


MU-STD-203E 


shall  be:  5.125"  and  0.063"  for  Requires  input  of  the  bottom  of  the  seat 

irs  and  transports;  and  3.125± 


MIL-S-9479B  (USAF) 


APPENDIX  B:  MILSTAN  - NEW  STANDARD  GEOMETRIC  AND  COMPOSITE  OBJECTS 


I I 

i 

i # 


GEOMETRIC  AND  COMPOSITE  OBJECTS 

y 

it* 

Standard  Input  Points 


H 

DEP2 

design  eye  point  (second  pilot) 

LDGGPICP 

landing  gear  position  indicator  centroid 

MANSIR 

manual  sight  range 

0XYGEN2 

oxygen  system  (second  pilot) 

^ ■ 

CMPQDSC2 

composite  quick  disconnect  (second  pilot) 

AGSUITC2 

anti-G  suit  control  (second  pilot) 

SHHARNL2 

shoulder  harness  lock  (second  pilot) 

SEATADJ2 

seat  adjustment  (second  pilot) 

NUTRLSR2 

neutral  seat  reference  point  (second  pilot) 

■I  Jfc' 

MAPST0W2 

map  stowage  (second  pilot) 

VSTADJ 

vertical  seat  adjustment  control 

VSTADJ2 

vertical  seat  adjustment  control  (second  pilot) 

* I 

I 


B-l 


. « 


\ #_PREC|pirC  r E BLANK- NOT  FILMED 


r 


Standard  Input  Planes 


LFVPTP 

LFVPBM 

LFVPLS 

LFVPRS 

LFVPFR 

LFVPRR 

RFVPTP 

RFVPBM 

RFVPLS 

RFVPRS 

RFVPFR 

RFVPRR 

LLPSEAT2 

IBSTPAN 

OBSTPAN 

IBSTPAN2 

OBSTPAN2 

LPSTPAT 

CSBTP 

CSCTP 


left  foot  volume  plane  - top 

left  foot  volume  plane  - bottom 

left  foot  volume  plane  - left  side 

left  foot  volume  plane  - right  side 

left  foot  volume  plane  - front 

left  foot  volume  plane  - rear 

right  foot  volume  plane  - top 

right  foot  volume  plane  - bottom 

right  foot  volume  plane  - left  side 

right  foot  volume  plane  - right  side 

right  foot  volume  plane  - front 

right  foot  volume  plane  - rear 

left  limit  plane  for  seat  (second  pilot) 

inboard  seat  panel 

outboard  seat  panel 

inboard  seat  panel  (second  pilot) 

outboard  seat  panel  (second  pilot) 

lap  strap  attachment 

compressed  seat  back  tangent  plane 

compressed  seat  cushion  tangent  plane 


Standard  Composites 
OVHDPAN  overhead  panels 


B-2 
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EXISTING  GEOMETRY- STANDARD  OBJECTS  USED  IN  THE  NEWLY  ADDED  MILSTAN  TESTS 
Points  - (37) 


LRUDPDCL 

AFCCP 

NUTRLSRP 

RRUDPDCL 

FEATHER 

WGFLDCR 

DEP 

RAMAIRTB 

EMGCYBR 

NSWHLSTG 

VCOMMHF 

CANJETSC 

POWLEVCP 

NAVCR 

DRGCHHN 

TURBRVTH 

IFFSIF 

DRGCHSW 

BSTPMP 

OXYGEN 

POWQUACP 

FUELCR 

CMPQDSCN 

TURBRVTH 

FLSYSLCR 

AGSUITCR 

SUPCHGR 

RAEBSTCT 

SHHARNLK 

COOLCR 

LDGGDN 

SEATADJ 

AIRSTSW 

LDGGUP 

MAP STOW 

LDFLPCR 
Lines  - (0) 

Planes  - (4) 

DEPZCP 

DEPYCP 

RRUDPDL 

LRUDPDL 

Composites  - (11) 

AIPITliT 

SEATPAN 

ALLPAN 

CSGPAN 

ALLCP 

POWER 

LCONSOLE 

RADIOCR 

RCONSOLE 

CONSOLE 

EMPAN 

THROTTLE 


C-l 


. ■ ■ 


— 
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APPENDIX  D:  CAD/CGE  INTERFACE  MODULE  SAMPLE  PROBLEM 


crnev'Tco  aipcp  m^TTON-AiLor atton  evaluation  system 


FEGIN  CAFES  » OEATc  n*w  PATA  "AN*/ 
PEC-IN  C A 0/ 

BEGIN  F 01  TOP / 

DEFINE  clc«cmt  ■ CDVT'>nU. POINT/ 
Atrcstprc  POTNT  ■ 0*0/ 

Length  . p/ 

SHA«>c  , 1,0, p,o, 0.1/ 

OCFINF  Tiirx-YCTF*  . *.i.?,  p Tl  TT  STATION/ 

OEFIMF  ciioFy'TrM  » -.1.1,  PT1.CT  SEAT/ 

0£F  INF  <tinFYSTC‘’  « ',1.2,  PUOT  PANELS/ 
OgcjNr  5,.orYFTCM  . *.1.1,  PILOT  CONTROLS/ 

OFF  INF  *||0FYST*V  . *.i.t,  PTI.CT  F YF  RFFEPENOE  PCINT/ 

OFF  INF  FimcYTTCY  . *.7,1,  COCKPIT  LINES/ 

0 E F I N c «-mocy*tfm  . *.  1,1  .PLANE*-  WITH  P/NY  BCUNCAPY  PTS/ 

SUB'YFT***  * *,1.1/ 

pr«7wr  ttcm  , pniNT*»*FAT  sack  / 
PPT*'T*  « 7.50,  122.75,  2 74.97, 

7. SO,  oo.i5,  270.60* 
-7.5C.  oo.i*,  27.1.60* 
-7.50.  172. 7F,  274,97/ 

TEFINE  ftch  . or)TNT*,5CAT  DJN  N 1 0 / 

POINT*-  - 7.5,ao.l «, 76 4.° 5, -7. 5, 99. 15, 26 4. 8 5,-7. 5,100.45, 257. e 7, 7. 5, 
150,4e*’57.P7  / 

Sl'P*Y*TF“  « *.1.2/ 

DEEthe  ITC»  ■ 74Nci,  hoped  LFFT  "ATN  TNSTPU  PANEL/ 

PAMC|  rngor  . 114. i«,  23F.46,  -3.63*  120.56,  237.56* 

. 

-11.00,  lit. 35,  238.46  / 

3r  P rijNO A o Y . -1.63,  110.35,  23°. 46*  -11.90*  11  6.35,  238. 4*. 

-O.so,  13«.4f,  238.11,  -6.06,  120.24,  2?7.53, 

-4.57.  171.33*  237.40,  -3.67,  120.56,  237.56/ 

ELF-cvt  . dptnt^ct  o\r  AL  T/PL/CE',FKT.  2.7C,  1.90  / 

EtCMCMT  . pf’tvt.  *?Er!'PpAK’F/Pt.  acf«*ent«  1.74,  4.35  / 

0 1 P T n f it:»  . 9ANC|  , l c o LEFT  HAIN  INSTRII  PANEL/ 

PAVEL  C?TPn  • 104. cf,  ?40.«5,  -3.24*  1 16.35,  23P.46, 

-14.74,  If**  .09,  24J.P5  / 

TP  PPl'VPAPV  . -1.74,  105. L9,  2 4 0.85,  -1  4.75,  105. C9,  240.  85, 

— 1 4.7*.  112.55,  239.26,  -13.48,  114. e9.  23p.fi, 

-11.90,  114.35,  238.46,  -3.24,  116. 35,  23L.46/ 

EIFNCVT  . PrtNT.FT *rrrL “TF /FL A<"F YPr T • 5. CO.  4.55/ 
EICPCKT  « ppT‘,T»FTAIo*PFep/?L/CE¥ENT»  6.2C,  1.65/ 
- eleyevt  . pot  N'T, rT  H TTMTo  /PL  A<*  F“F6’T  • 9.5P,  1.65/ 

E l F “ F v r . pctnt.ftai'0(  ayaK/PLACF**fit»  10.15,  4.55/ 
EIFMEVT  • PriNT.ein* cvrrTp/PLACf 1FNT»  4.55,  F.OC/ 
EIFNFNT  . opT.|T,ET*TPPYAPI/PL  ACENPf  T«  3.30,  1.13/ 

EIEKCVT  ■ PrTNT»FIVcoTVcl  /PLACCMCKT.  7.50,  4.55/ 
E,FMEMT  . nriNT.Fiici  CUANT/PLACE-CNT*  2. CP,  4.05/ 
EIFNFN-*  • orTNT.H*ro  ritvcT/FLACFOFNT«  7.75,  7.75/ 

C|Fyc»>t,  ootmt,u*ao‘,*tat/pl  ArrHFNT  « 9.6O,  P.5C/ 
El  F ** e N T • POIMT.WFFJLWJ  /FLACCPFNT  - 2.19,10.87/ 
EJFYE.-T,  PnTNT,W**ct JETT/PL ACFHcNT  « 7.15,10.40/ 

1 CECINE  TTFN  « PANFL,  CFNTCP  mail  insTbu  PANEL  / 

PANEL  fl?poo  . 2.11,  lor.09,  24u.8?»  2.31,  116.35,  238. *6, 

-’.74,  105. C°.  240.85  / 

30  EOL-NPAOY  . 2.31  , 11*. 35,  238.46,  2.31,  105. C9,  740,85. 

-7.74,  n«.0°.  24w.e5,  -7.24,  116.3!,  238.46  / • 

\ # PREC|T}pC  r'ApS  J3lAN3C.NOT  FILMED 


■w 


1 


FLEPENT  • pOTnt.af acul  /pIACE*fnt»  1C. 93,  2.62  / 

ELFpcrT  . POINT  , APALPL  /PLAFIKFNT*  30.93,  0.97  / 

ELEMENT  • °PTk'T.4PAMr  /PLAPCMCNT*  10.93,  4.42  / 

ELEMENT  • ’>PT‘'T,M4PT  /DIaCcmek'T.  7.°2,  2.62  / 

F L E 6*  F ►'  t « °OTk,T  , c 7 aotct  /Pl4rE"E«T«  5.73,  C.60  / 

ELEMENT  - dph't^ct-sT  _ /PIACENFNJ. ?. 52,  2.4-2  / 

SL'P'Yftfm  ■ '.I  .’/ 

OFFTNF  I T c m . pnrk'T,  ArTOTLT  /POINT  - -76. iO,  1 30 . 4C» 2 PI  .70/ 

OCCTMC  TTC»  . pptnt.aFTpT&EAF  /POINT  « t. CO, 321. 9o»?00. 20/ 

C F F I ►'  c TT  c w • 00 1*' t ,aft°TPT  /point  - 26.uG>  C .Co,  2*1 . 7o  / “ 

f)FFTMC  TTCM  . POINT.  WUTOL^PP  /POTNT  • C.GO,  99 . 1 5 , 270 . 6 0 / 

_ pcpfKF  tttm  . point, Fco  POWN  /POINT  • C.CO,  9 7.24,770.00/ 

DFFTvc  ttcv  , pttnt.ppp  *J P /POINT  » C. CO, lu  2.  Cl  1,271.50/ 

TEFINF  tt:»  . o (_  a v c , TOP  OF  THPOTTLE/ 

P13NAP  Pfctntttpm  , -11.43,  104.76,  249.93,  _ 

-I’.o*,  106.76,  249.93, 

-11.42,  lu7.06,  250.63/ 

P F F T 4'  F T T F ** « POTNT.CCTNPTLFWO/ 

PL*4'r  • TPP  "C  TUPOTTl'C  / 


2T  POINT  . 1 

.26,  0 

.01/ 

SI'RFyttfm  , t, 

1.4/ 

0 c c t m c ttcm 

T PD, 

PILOT 

cpp/ 

PP I *!T  *■  « 

O.OC. 

3 ’0. 

4), 

265, 

.10, 

5.00, 

1 30. 

40. 

265. 

.13, 

c • oo. 

1 ’0. 

40, 

260. 

,10/ 

SUR9Y9TCM  . f. 

’.1/ 

0 1 p I w r TTCM  . |.  INCF,  7ATT5/ 

PPTN'Tf  ■ 0.00,  130,4  3.  P65.io,  C.CC,  131.40,  265.10/ 

0 E F I N F TTf  “ . I ^CT.-TCCM^py/ 

PPTNTC  . o .no.  130. 4",  ’65.10,  -7.11,  115. 7P2,  ’?8.5ei/  

OfCTNF  TTCM  . I TNFF , VO AVCvn / 

p p T m T f . o.po,  1 ’p • 4 0,  ’65.10,  O.OC,  121.90,  220.0  / 

SC33YFTCM  , p . ’ . 1 / 

C F F r tj  r item  . -ro-ic.r^p  r.CMpp  flP  TI-iPCTTl  E / 

PIAN'F  . Top  OC  TMOOTTl  F /OCINT  « 1.26,  l.Zt/PAPluS  • 1.26/ 

C t F I f'  F YTr“  » POM  TC,FC  «T  0..J  f p I cup/ 

POINT*  * -’.74, 100.4*,  757.  p’,  -2.50,  ICC'. 45,257.62,  - 2 . 75 , 1 00 . 4 5, 2 5 7 . £ ? , 
-3.43, 100.45, ’5’. P’,  -4.50,100.45,257.52,  -5. 50, 100. 45, 257. «2. 
— 6. 50,1. ». 1,4  r. , ’57.pt,  -7 . 50,  1C  C . 4 , 2 5 7 . P 7 , -7.50,101.27,253.29, 
-6.«3,toi.?7,t*t.3Q,  -5.5o,1C1.27,253.39,  -4.50,101.27,263.39, 
-7. 50, 131, 27, ?53, 30,  -2.2 5,101.27,253.39  / 

FNt  EOITOF/  

REPIN  ppprcT  cc»|co*Tro/ 

P F P3PT  * 6 A T A »JMI(  Tt|MM(0»/ 

_ CATAPORY  . At  t / 


PononiNATp  system  scp^aby 

OEWEY  OEPINAL  NIUMPCP  ennPDINATF  SYSTFI*  N A P F 


PPIN/PY  COOPn  NATE  SYSTFP 


coordinate  syptp***  <■.0 

optxaov  CPOROT^ATE  SYSTEM 

DEFINING  POINTS* 

V Y 


.0 

1. 000000'' 

.0 


SUBSYSTEM* 

S.O 

S.1.0 

M.l 

M.? 

*.!.? 

*.?.l 


.0 

.0 

l.OOOOOtO 


PRIMARY  SUBSYSTEM 
PTLCT  STATION 
PUTT  SEAT 
PIICT  PANELS 
PILTT  CONTPCLC 
PTLCT  EYE  PE  FT  PENT?  POINT 
COCKPIT  LINES 

PLANES  WITH  -ANY  P.Ct'NPAPY  PTS 


DEWEY  OFf T“At  nijhbco 


s.c 

S.l  .0 

_S.1.1 _ 

5.1. 2 

5.1. 3 

5.1  .A 

5.2.1 

5.3.1 


SUMMARY 

SUPSYSTF*  NAME 


P®  T“ A S Y SUBSYSTEM 
PTLCT  STATION 

PTLCT  SEAT  

PTLCT  PANELS 

PTLCT  CONTOdS 

PTLCT  F YE  PEf FPENCE  POINT  _ 

COCKPIT  l Inc« 

PLANES  WITH  MANY  EOUNCAPY  PTS 


SUBSYSTEM,  s.o 

pp T m A PY  PtlBSYSTRX 

C OOP 0 IN  AT  e system*  r,o 

pp  T m A 9 Y PHCPOINATE  SYSTEM 


GEOMCTPTP  T TCMS  AND  PANCLs» 


SUBSYSTEM,  S.1,0 

P Tl nT  PTATTON 

COO COIN  ATP  SYSTEM*  C.n 

PP T M AP Y COORDINATE  SYSTEM 

GECMFTP  TC  ITEMS  AMO  PANFL<« 


SUBS  YSTP  Mi  S.i.T 

PT l OT  SEAT 

COOROTNatp  SYStpx*  c.o 

"PT-apy  coordinate  system 

GFCMETptC  TTF-p  ano  p a n E l * 1 
PEAT  B ArK 

SFAT  PAN  Min 


SUBSYSTEM*  * . 1 • ’ 

°n  ot  c "NToni < 

• 

. \ 

COCPOTNATF  SYFTF-.  {-,0 

ppT“A0Y  COOPOINATF  SYSTEM 

GEOPETPJf  T TF“F  A N c'  PAMFlct 
A F T°  TL T 
aftptpf  ap 

jCTPTPT 
Mt'TPL^PP 
coo  n^VN 

cop  IIP 

top  ne  THPOTTLf 
FC Tup  TL  cUp 

‘ ' I 

SUBSYSTEM*  t *.1.A 

PTLnT  c YF  p£C£pcvrF  POINT 

1 

CCCPPTNATC  SYSTCvj  r ,f) 

>PT‘*yPY  COOFCINATC  SYSTEM 

GEOKEYPtr  ttcmc  amp  panel** 
PILnT  fop 

SUBSYSTEM:  f,’,’ 

rPCK°IT  ITMes 

I 

COC°DTnatf  cr«Tt«.  r. ,o 

p p I M / p Y COCP  D I N A T c SYSTFN 

1 

GEONETP  TO  TTemc  4fJo  ® AN  Ft  r t 
? A Y T S 
PFcyr^  o y 

VPAYFwn 

. 

SUBSYSTEM  f.’.T 

0(AA'FF  uttw  “any  phunOAPY  PTS 

CUOPPTNATt  SYSTr-s  r.o 

P P T M A ® Y rpCPPINATF  SYSTEr 

• ~ ' j I 

G60PETPIC  TTF«*  M'n  p a n r e * 1 " ‘ 

TP®  f c n r f o np  THPOTTLF 
T F A T PAN  E cc  T py o 

SUBSYSTEM  f.j.? 

pti  nr  paa'ces 

_ 

COOBOP'ATF  fyftfhi  r.o 

PP  T M A ® Y PPCPOINAT;  SYSTEM 

GEOMETPTr  ttfh*  a no  panfe** 

UPPCO  E F f T NAIN  TNETFl)  PANEL 

Lowe®  LrcT  MAIN  TNFTFU  ® A N F E 

_ 

CFN'TFo  “AIN  I NS  T®  U PANEL 

?! 


C-ETMFTRTC  ITf« 
ITFP  NAHFC 


SEAT  BACK 
SEAT  PAN  MTP 

aftptit 

AFTFTRf AP 

AFTPTRT  

NUTFISRP 
SRP  DOWN 
SRP  U° 

TOP  IF  THO^TTLC 
FCTHRTIFwO 
PILOT  FPP 
7 A y I s 
Of F8CIRY 
VK  AY  FUf) 

TOP  C r NT Pp  pp  tmoptti  r 
SEAT  PAN  LccT  P'JP 

GFoVf T R ! C TTtm;  cc4t  back  ~ 

POT  NTB 

SUpSYPTF«s  S.Y.l' 

POTnT«  » 

» - v 2 


7,'O‘jOOO  122,7*00  2 79 . 97CC 

7 . *OC  GOC  99.15000  27C.6C00 

—7. *00000  99.1*000  27c. 6000 

-?,rr>rr>r)''  122.7500  279.9700 


C-ETPETRIC  TTP^:  SSAT  PAN  VTO 
0 0 T N T < 

SUPSY^TCMt  *.1.1 

POINTS  i 

y .—  y 2 


■».  500000  1 50Cy  _ 26*-. 8500 

-7. *00090  oq. 15000  2AA.85C0 

-7. *90000  100.9500  257.P2C0 

7. *00000  13C.95C0  257.P2C0- 


GEGOETRIC  TTCM  s 4cT°Tl  T 
PITVT* 

SUB  S Y *TC *• ! S.1.1  , 

POTNT«t 

y - y - 


-26.00000  130.9000  2P1.70o0 


GEOMETPIC  TTFM t »'TPTPCjs 
“ 0 T k'  T S 


SUP  SY ?TFM  » S.1.3 


POINT?  t 

Y 

Y 

7 

.0 

121.0000 

3Cw.20C0 

~ GEOF'ETPIC  T T p M t actctot 

P 0 T N T ? 

-•  * 



SUB  SYSTC*  t *.1.3  . 

POINT?  t 

Y 

r 

7 

76.00000 

.0 

281.7000 

• 

GEOMETRIC  ttf«!  m m T p | ? o o 

onfK’T? 

?UPSY?TF*t  ? , 1 . 3 « 

POINT?  » 

X 

Y 

7 

.0 

O0.l?oo0 

270.6000 

GEDMETpIC  JTcm.  pop  nnun 
POTNT? 


SUP  5 YSTF*  • s.1.3 

P0TNT?  s 


.0 


°7 . 2 ROCO 


27v.CJCO 


GEOMETRIC  TTrM?  ?pp  Ud 
P 0 ? V T ? 


SU»SY?TFH;  S.1.3 
POINT?  i 


.0 


102.01CC 


271.50C0 


:ECI“ET°IC  TTFW!  Tno  ne  tmphtti  F 
PH  VF 


SUP$Y?TTwt  ?.1.3 


COr'PrIk'«TF  nrcfNTYTnNt 

POINT?  S 

Y V 


-11, ‘Ynnn 
-1  ■»  ,0*1  nf 
-i i .ipcno 


Y Of  .7660 
10*.Y*Cfc 
TOT.O^CO 

D-6 


24<5.9300 
?*' >.°309 
2 S 0 . t300 


9 

t 

9 


GFOPETRIC  !TF":  crTveTLcwf' 

PpTNT«: 
SUPSY'TCMt  <.1.3 
P0T*’T9t 


-12.6Q0C0 


1 J6.7639 


2*9.9392 


* 

i 


GEOrETRIC  TTCM»  PTtnr  ppp 
PEC.  POIHT 


SUPSYrTP**?  9.1.* 

Cpnp n T N 4 T £ PCClNTTyONS 


P0TKT<» 


.0 

5.00C000 

.0 


no. *ooo 

1 3C • *000 
1 3C , *0C0 


2t5.1otO 

265.10C0 

2 to  . IOC j 


GEGPETRIC  TTO*?  7i»T< 
tTMC< 


SUBSY<TCM?  9.2.1 
POt*'T<  t 


V 

r 

z 

.0 

130. *000 

265. 1CC0 

.o 

131. *0C0 

265.10*0 

~ CECrETBIC  TTCMt 

nccMri.  py 

- 

5UPSY<TP«t 

9.P.Y 

POTNT<  J 

y 

Y 

Z 

.0 

no.*oco 

265. 10CO 

-P.ll^OOO 

ll‘.7°20 

232.5310 

GEOMETRIC  TTC^ ? 

v'BftyrwO 
l inr«r 

SURSY<Tc«t 

9.2.1 

POTMT*  J 

y 

Y 

2 

.0 

’■»o.*nco 

265. 10C0 

.0 

121. °000 

230. COCO 

GEQ^ETRir  TTf**t  rno  reject)  nc  TMPlTTl  F 
r i»ri c 


9Ue$Y7TF“i  «.’.1 

PQTHT?  t 


» 

V 

7 

-12  .‘‘.anoi' 

1*7. 7527 

252.246? 

-'  J.O'int 

107.7<,82 

252.7359 

-1 

107t7360 

752.2051 

-n.iojoo 

1 >7.713? 

252.1543 

-13. ’>’1’ 

1 37.6P?4 

252.0046 

-1»  .47000 

1 >7.445'’ 

251. <5070 

-1’.'a577 

107.4014 

251  .8932 

-1  7 

1 >7.  e<503 

251.7751 

*5 

107.4949 

251.6447 

-1’.  0*501 

1 07.4747 

251.5C44 

-1  * .01  **o 

107.3714 

251.3566 

1 07 , ’060 

251.2040 

-I’.oioir 

1 >7.?’9P 

251.0494 

-n.03?4>- 

707.17?? 

25C.8955 

7 >7.1043 

2 5o.?45C 

107.7474 

250.6006 

-1 > • 7*204 

704.9P93 

25u . 46  50 

-1  ’.*577^ 

106. 9750 

250.34C4 

-1  ’ . * ’ r 1 °. 

lvlb.BPf  ? 

24^.2292 

-’  » . 4C700 

106. “471 

250.1333 

IO4.0133 

250.C545 

-I’.l'i”! 

1 a6.7»7i 

249.9941 

-12. >490-1 

106. 76“9 

249.9532 

-17.77416 

104.7611 

249.9326 

-77.*0r°4 

1 >4.7611 

?4°.47?t 

-7  2 .4 ’OOO 

104.74CQ 

249.9532 

-1’.276fr0 

1 04 . 7875 

244,9941 

" 

106.O13? 

2 5\j  • 05  4 5 

-11 .07' >1 

106. 0471 

25C  .1323 

-V 

106.ono? 

250.2292 

*7  7 ,7773^ 

7 04,97*9 

250.34C4 

-1  7 ,*->70f 

104,069? 

25J.4650 

-1  1 .04707 

107.0474 

250. 6006 

-7  1 .40467 

107.100? 

25^.7450 

-11.44756 

107.1730 

25C.8955 

-11.47070 

107.?7C° 

251.0494 

-11 ,47fi77 

107. ’060 

251 .2040 

-11.4447? 

1 >7 , ’ 7>  4 

251.2566 

— 77 ,41410 

107.4747 

251.5044 

-11  .5  0?A4 

1 >7 , 4040 

251.6447 

-1 1 .47447 

1 07. ce0p 

251.7751 

-7 1 .7°4?d 

107.6314 

251.6932 

-7 1 . °C°1 ’ 

107. 4459 

251.9970 

-17.047RO 

1 07,4O?6 

257.0846 

-7  7.1 QQ11 

107.7133 

252.1543 

-IM'711 

107.7350 

252.?C51 

-17. '7774 

107.746? 

252.2359 

-1?.6>006 

1>7.7627 

252.2462 

GEOMETRIC  ITp^i  SCAT  ban  LEFT  FWH 

°PT  VT* 

SUBSt*!*'*!  S.?.! 


PQTNT<  * 


V 

r 

7 

-2.75C00O 

100.6500 

257  , R200 

-2.50009" 

lou.  6«>co 

257.P20C 

-?.7«^noo 

130.6500 

257.6200 

-7,*r*Aif.r. 

? 30.65 00 

2 57.P2C0 

-*.  ?o"oc»o 

1 J0.65C0 

257 . 82oO 

■ -5,«‘<v>nr>c 

190.6500 

257.6200 

-A.*9C090 

ioc.«Ktc. 

257.820 0 

-?.*C900C 

100.6500 

257.P7CC 

-Y.'-Ot’O.™ 

191.’7(.y 

253.2000 

-►.e^nnor 

101 . ’7C0 

253.29CC 

-*.‘o:oic 

1 J1.?70P 

253.3900 

-*•.*  oco^o  • 

101.’700 

25  3.39C0 

-’  • r0  390© 

nil  ?7cc 

253.3900 

-2.7*3000 

101.7700 

25  3. 39C0 

INSTPUNE*:T/rPNTBnL  panel 
PANEL  NA-PP 

EMM “ AP  Y 

. - ■ — » ~~  - ---- 

UPPER  LTFT  **Atn  IN^tph  oanpl 
LOW F°  IFFT  “H>!  nn-Tou  oanpl 
CENTER  yaIN  t»’«:tpu  panel 


PANEL*  U P r c p > CCT  “JTN  tnptoi)  PANEL 
SUPSYETE*'*  *.1.7 


PANEL  CCnP0Tw*T=P(v,Y,7)t 
-3.*7on"0 
-’.530900 

118.35CO  . 
1 29. K6CG 

238.6600 

237.5600 

-11 .ooooo 

P OUNO  AP  Y ( Y, Y1 t 

.0 

17  A. *500 
.9 

233.6600 

.0 

2.1  574,57 

* 5,000417 

P.7790C0 
r. 0*0000 
2. 3 50000 

* , 0°1 5*0 
‘.lOM’* 

. ‘*003000 

.0 

ELcHpmts  o n t n t 

ICC  at  THAI  dot  NT  * V * Y 1 * 
THETA,PMI.L,C.r.HT  , 

ELE"P1  T ! M*[  i pi  ojo 

2 • 7C00o0 

.0 

ALT 

1 .900000 

.e  .o  



ELEMENT*  pp^NT 

LCC ATtom  oor..Tf)((Y)l  1.7ty00o 

THETA .ouT.wP’rMT:  .o 

ElE^F^'T  t Aoci » roet^POAKF 

6.350000 

.0  .0 

I 
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P*NF  L * LCwr'>  l c c T *»tm  tkstpij  panel 
5U8SYSTE“:  *.1.? 


PANEL  crPPi'TN»T  = '«v,Y,7)  i 

-’.?<.  v»oo 

-7.7PCP00 
-1*.‘Y50''0 
FOUNC«BY(v, v>  j 

.0 

.0 

7,P?7?i5o 
C,«1  A757 

ll.«’0«r 
■ U.«I0°5 


ior.0900  2‘o.esoc 

ut.’*cc  _ ?3P.<.600 

loe.oooo  " 2<.G.esG0 

.0 

n .5ioco 
11.51000 
10.?‘0C0 
6*0000 

.0 


ELEMENT:  PfiTMT 

lOC*Tin»)  ppT»TfY,Y»t  5.PC0000  4.5S0CC0 

THET«,ouT,HcfruT.  . 1 #0 

ELF*'c‘,T  l lotf.  M&rCcLl*TO 


ELtHFATs  °PTk'T 

LPCiT’n*  PnTMtu.Yii  (■  .700000  1.65CC00 

TMCTP.PUT.MrrruTt  . P ,C 

flfYO'Y  L4BCLJ  cj«TB»otpn 

ElEHfMl  PnTMT 

LCCaTtpn  ppr»iTf*,Y1i  9.560000  1.650000 

TuCT*,PU*,L|C:tj~MT!  ^ <0 

ELF^'T  I AR*1  » tTUT’“TP 


.0 


.c 


.0 


ELEMENT:  rnrtJf 

ICC^Ythw  ppTwTfY.YM  10.15000 

TMgT* , PUT ,Mc  rrnT t .0 

.0 

<..550000 

.0 

tlETMT  I Aori  t ctamphtaK 

ELEMENT:  PnTwr 

l GCATtom  on’wTfY.YIt  a . 5 50C00 

ThEt*» put ,hc Trur • , ^ 

EIEmpp'T  Li°eLt  rTs<;cvircTP 

.0 

8.CCOOOO 

.0 

ELEHEMs  pptmt 

tUCiTTnv  PnT«T|»,y.D  1 • 3 C0000 

1.130000 

theta, put .ucrruTs  .0 

ELE^EP  T un't ! cr^TopYArr 

.0 

.0 

£ l E * F A T : point 

LCC*ttpa’  optut  ( y,v  ) « 7.500000 

THETA  , put  , uc  ’MI  t .0 

.0 

<..550000 

.0 

ELET^T  l aoci  t PIVCPTWCI 

£^£*£(■7!  POTMT 

* 

LOCATION  opTMTfy,Y)J  ?. *60000 

THETA  , PUT  .UCTf-HT  ! .0 

ELE*'CVT  lAPCtT  cUcl  PpANT 

.0 

<..050000 

.0 

FlEMCNT:  pptmt 

l OC  A T TO*  PPTKIT(Y,Y1J  7.750000 

7.750C00 

THPTA .put .uP'fny • , <r 

Elf'CNT  lA«clt  “STP  FUNfT 

.0 

.0 
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ELEMENT*  PfV»MT 

L PC  a r r prTVTfVjY)* 

THE  Ti,tnjT)HCTrHTt  .0 
ElE"cNT  I « o r t.  s USAP"FTAT 

E LE'S'cVT  * »n»VT 

LOCATION  i>ntMT(»,Y|!  2.1900CC 

THETA, PHT.u'-TruTs  .0 
ElE"F*-T  (_  A°cl  S W S P A L V J 

ELEMENT*  cnTNT 

IPCATinw  onTHT(v,V)S  7,150000 

THF.TA.Pur.wcrrMTt  .0 
E L ’ " ’ T ls°ct.  s yp«ElJPTr 


PANEL*  L'PPPP  I c c T “(*N  ynFTOII  PANEL 
SUPSYSTE*'*  '.I.? 


PANEL  CCnP0TNATPP»»,Y,7)t 

-3.*300A<0  Ilf. 3500 

-’.A’OOCO 13O.55C0 

-11.90000'  1 1 Ai,  35 CO 

POUKCA3YO<,Y1 * 

,0 .0 

.0  P. 770000 

7.157A5’  5.9*0000 

■»,0004*Y 3.35 0000 

*.0015*0  .9000000 

A. 3051’*  .0 

IlYhP  HT * D 0 T N T 

LTC  A T*om  PfJT  NTfX,Y1l  2 .700000 

THETA,ewT,LtC»r.HTs.  .0 

FLEHPf  T ( a 9 c i f PI  P » n ALT 

ELEMENT*  PPTNT  

LCCATThm  pot »Tfx,Y)i  ' 1 .7£o000 

THETA. OUT.HPTPMT:  .0 

_ EIE“FA'T  L apcL  *_?  p c F 0 ’ 5 AK| 

PANEL*  C E A'Tr 0 "ATM  TV'PTPH  PANEL 
SLPSYSTE"*  %1.7 

“PANEL  CPPP0TNATP<-(V,v,7)t 

?. 910000  105.D900 

7.  p’oonr  HA, ’SCO 

-’.PA-'OOO  1)5.0000 

P PUNC  ARvST.v* t 

11.510p*  ' .0 

.o  '■  .0 

.0  «.s?00CO 

l’.510»r  r. 550000 

flENENT?  P 0 t N T 

ICCATTHm  pnTvT(»,Y»s  10.930U0 

THETA.OUT.HMfUTt 
ELF"rNT  t ABC|  T ATAPWL 


FlENkNTt  PPT*'T 

ICC  A T*f*M  OHTVT  f Y,  Y1  t 
THFTA.ouT.wr.rUTt  , 
E irwCNT  t APCL  5 *<“  M PL 


10.93000 


8 . 50  C C 00 


0 
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E Le "E  NT  t PC ’NT 

l CC  A T Tr*‘  °cti’t(Y»y)s 
THcTA,our,HCTrHTt  .3 

El  F*‘C‘,T  ISOClt  AC  SMC 

10*43000 

.0 

4.420C0C 

.0 

f lF*f NTt  POTNT 

LPCAT’nv  »o»  »’T  1 y , Y ) • 
ThEta.put,hctcmT?  .3 

FLEvfnt  l A ppl  : c ! ACT 

7 . P200C0 

" .0 

2*620000 

.0  

ELEHFMt  POTUT 

LOCATJCV  PQTN'T  f y « Y ) S 

THETA  »°uT  »tJCT'“1-,Tt  .3 

r .730000 

.0 

.P000C0C 

.0 

FI  Cxfk'T  l S P c | t p TACT  = T 

flFHOTi  rpn'T 

L OC  ATIPI'  onT*.T(Y,Y)! 
THFTs,pui ,wcrruTi  .3 

ELEMCNT  • a D p l t p T t 

2.520000 

*c 

2.620000 

.0 

INSTRUMEM/rn^Tont  rpn^p  SU*“*APr 
GROUP  K’iKPr 

NQNF 

CAT  4LOC-ED  c|Pmcmt  <:iimm4oy~ 
ELEMENT  VAMPS 
. POINT 


ELEPfNTj  ofT'-'T 
T Y° F : CCVTqc(_ 

pgFECCNCt  PPT‘'T(v,Ylt  ,o 

LENGTH!  .0 

SHAPr  T vp c ! r reri'i  »o 
SHAPE  DP^CPTPTtnMfY.Y) : 

.0  *o 

-CACTI'S?  .1C0000C' 
HEIGHT  APnVc  pshci  . ,f) 

‘END  PfPCPT  GFMCPSTrp/ 


ENP  CAO/ 

9FCIN  CC-F  TNTPPPAHr/ 

PUNCH  • CAP  PJTl/ 

STTPAP-F  * l T*T/ 

fpp  • PT|pT  epp/ 

COCKPIT  prsrorovTnM  . 47F,e-»c  COCKPIT  PILOTS  STATION/ 

• *.1.7/ 

SUPSY*'Tr>'  * v.T.a,  *.T.T  / 

pijNCM  . r*r  rjTi/ 

PUNCHING  OF  FTrusrc  I'm  i‘p»o(.PTcn,  60  CAPTS  WEPE  PUNCHEO. 
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lTrTTNft  0=  oi'NCwEO  PECK 


T A n | r na«*c  • ccickptta’f 

TMT«  r»r<  rcr  contains  a SFT  CF  VFPTIC1ES  CCRPE?  PCNHTNG  TO  EACH  CCCKPIT 
PLANE  Tv  tmf  a’F  COCKPIT  PILOTS  STATION  . 

UPPFO  | rer  V)iN  TNSTOlt  PANEL  1 6 


-3.*’0 

’6.4*0  -14.050 

-11.000 

26.640 

-14.05C 

-9.5PO 

27,051  -11.94C 

-A..OPO 

’7.47ft  -10.140 

-4.520 

27. 7w  4 

-9.071 

-3.630 

27.540  -0.8*0 

Louc®  iffy  hatn  tnf’-oh  panel 

2 

ft 

».’*u  -?  * . 3 1 0 

-14.750 

24.250 

-25.310 

-14.750 

25.434  -17.  ®49 

-l’.4°0 

?».’««  -n.’ie 

-11.000 

26.640 

-14.050 

-3.240 

26.64^  -14.050 

Ccntfo  *A'v  t v s t p U P Aft f L 

3 

4 

’.’10 

’ft. 64?  -14.1*0 

2.310 

24.250 

-25.310 

-3.240 

24.2*0  -25.310 

-?.’40 

’t.A-AC  -14.050 

5 E a T n acy 

4 

4 

7.«P3 

-c.370  -7.4;n 

7.500 

-5.500 

-31 .250 

-7. SCO 

-5. 500  -31.25C 

-*»,  «-nn 

-o.°’C  -’.ftfO 

SF  AT  PAM  *T" 

5 

4 

• 

.’50  -31.’r0 

-7.5O0 

.250 

-31.250 

-7.5CO 

7 , 2 °0  -25.550 

7.53C 

7. ’BO  -29.950 

T A°L  r NA**F 

* 

T A PL  r NAME 

THTC  err  nr  '■^trnr  CP  A frrKFIT  CCNTOPL  COPE  DICTIO'APY,  WITH  CCNTRCL 

COTF  v.MCC  A.*  r>  cn»T3CL  CnPF  CHORD! NA  T F S IN  THE  E F P COCPriFATf  5YSTF“ 

FQP  TWC  A7r  f O'kpt T p TL  OTS  STATION 
27 


fipacalt 

-5.c70 

’7.20* 

-11.410 

1 

JpCFTOP  A K F 

-7.FP  Y 

’7. POP 

-12.379 

1 

F I A C C F |_  MTP 

-7.790 

25.26? 

-’C .4i9 

7 

FIATFpocrn 

-4.ocn 

’5.537 

-15.245 

2 

F IALTT  **To 

-4.  BOO 

26.235 

-16.535 

2 

fiancl  ATak 

-7. 700, 

’6.357 

-15  .361 

2 

pjp^rvrrro 

-11.2*3 

’5.:oc 

-?t  . P65 

2 

F I FTr  o Y A n T 

-4. ’70 

24.935 

-22.042 

2 

FIVFCTVFL 

-7.700 

’5 . ?07 

-17.973 

2 

Fljr|  Ol'AVT 

-7.200 

’4.662 

-23.275 

2 

A-5TPFIIVF  T 

-10.5CO 

25.655 

-17.729 

7 

WSAP“’ TAT 

-11. ’*0 

’6.2*3 

-15.515 

2 

W s r » L V .! 

-i4.no- 

’4.705 

-23.168 

2 

VSFFI JCTT 

-13.6*3 

25.735 

-16.316 

2 

ACAFWl 

-.310 

74.515 

-1 4.616 

3 

AC  Al b l 

1 . ’ 4 0 

’6.515 

-14.618 

3 

AC  A A»r 

-2.110 

26.419 

-14.616 

3 

F I A P I 

-•’ID 

’f . 874 

-17.660 

•a 

FIAPTFT 

1.  .e10 

75.4*0 

-15.705 

3 

t [ M?T 

-.’10 

’4.77? 

-22.845 

3 

A F T P Tl  T 

-’6. Pol 

-16.600 

• CwC 

-0 

AFTPtpcao 

.003 

-35.1UO 

-F.5O0 

-0 

A F T P Y 0 T 

’6. 003 

•l*  • fcOO 

-130. 400 

-C 

M(T®1  ’ PP 

.0C3 

-5.5CP 

-31 .250 

-0 

5 p pppyw 

• OoO 

-4 .90o 

-33.160 

-C 

SOPI'P 

.000- 

-6.400 

-26. 350 

-0 

FCTOPTI fuP 

-12.603 

l'.ltl 

-23.636 

-0 

T API F w A “ F 

• 

T API  r NA"F 

• rnK*uiP&y f 

THYS  pata 

fct  n c f | n c f 

THE  NAPES 

OF  CONTPCL 

SHAPES  ANp  COCKPIT  OBJECTS  AND 

THC  I®  cneoe^onNOTNr.  e>i  Anp  PEST GNiTTCN  MJf*B E R 5 USING  LOWER  *KO  UPPER  P0UM5S 
? 

PILOT  PAk|C(  e 13  _ 

PILOT  TPii  ' " * 5 

T4P( C N»*F  a 


plants 


S F AT  ® A ^ w 

S»TP 

4 

7.  *ro 

-9,»70 

-7.450 

7.500  -5.5UQ 

-31.25C 

-7. SCO 

-5.5C0  -’1.250 

-7. SCO 

-0,070 

-7.650 

SEAT  PAN 

»Tr 

SPANHTD 

4 

7.5C0 

,740 

-■>1  .’SO 

-7.500  .’50 

-31.250 

-7.500 

7.2PO  -29.950 

7.«CO 

7, 700 

-?0.0«0 

(jrorp  lcct  matn 

tnstpo  p a n p 1 ppANcwni 

6 

-? . A?0 

-14.  )eo 

-U.9}0  26.640 

-14.050 

-9.5P0 

27.C91  -U.94C 

-A..QPO 

77,<,74 

-10.140 

-4.520  27.7v4 

-9.071 

-3.630 

27.540  -9.P40 

trvpp  l c F T W«TN 

TNCTPU  P A N P L U l K T P A N 

6 

-3.740 

’4.750 

-’K.’IO 

-14.75C  74.250 

-25.31C 

-14.750 

25.P34  -17.349 

-IT.407 

?4.,90p 

-1 *.71" 

-11.O0C  26  ,640 

-14.050 

-7.240 

26.640  -14.05C 

^fKjTro  M 

AT*’  tnjctdi:  PAM  El 

LIMPAN 

4 

?,’1A 

74,t 4C 

-14.050 

2.?iu  2 4.250 

-25. 311 

-3.24C 

24.250  -25.310 

-3.?40 

’6.44 0 

-14.050 

* 


STCPAO*  ■ IT'TP 
ffp  ■ pii nT  =pp/ 

COCKPIT  rrrppiPTTnn  . 47c,A7f  PHOT  STATION  WITH  2 SUPPTVTDFr  PLANES/ 
SUP  S Y ST  cn  - ».T .1 .3,9. 3. IP 


THE  FOLLOWING  PLANc  TMUrwi  wnpc  THAN  STY  POl'NOAPY 
PGIKTS  AND  WA<-  TiionTVTPPO  T NTP  1?  PIANFS 
TOP  CfcNTFP  r>c  THcrTTLp 


THE  FriLPVH'P  »l*"e  'TVTjTMcr)  mopc  Than  51*  fqindapy 

FOUNTS  AND  v a r fijanrvrncn  T NT  n 3 planes 
SEAT  PA*-’  ! P r T fgn 


FP  0 CO  F TNTPP  F Af e A 

PUNCHING  0,F  STnPA«-c  n(T,  rn«PL  = Tcp.  lot  CAPCS  WEPE  PUNCHED. 


D-15 


— — ^SSLSl 


tl'TTWr.  pc  ot'MOHFP  DECK 


T*»ir  ='»“C  . rnfi<pTT*7f 

THT»  f«T*  err  rrvT*TN*  A 'FT  [t  VPRTTCIES  CCpf  F F PCA’P  I NT-  TC  EACH  CCCKPIT 
PL#NP  T‘l  Tuf  47=  otlht  STATION  WITH  2 SUBOIVIPEC  PlANfS 
2C 


Upper  Lcct  "HN  tmSTQU  P4NFL 

1 

6 

-?.6’0 

7F.F40  -34.0*0  -11.000 

»(  . F.4U 

-14.05C  -0.560 

>7.091  -11.940 

?->,L7t,  -10.140  -4,020 

27.704 

-9.071  -3.630 

27.5‘0  -9.S40 

tcPT  V A T M Tnrj9t»  DAKFt 

2 

b 

-’.240 

74.7=0  -?e • 310  -14.750 

24  .250 

-25.310  -14.750 

2 5. 634-17. P 4 9_ 

-17.4°o 

74.2°°  _i  = ,7io  -11.000 

26.640 

-14.050  -3.240 

26.64C  -14.050 

C'k'TtC  »»U'  TVCTcp  P4VC| 

3 

4 

P.’IP 
SF  AT 

?*.*4C  -14.0‘r  2.310 

7F.440  -14.150 

2*. 2^0 

4 

-25.310  -3.240 

4 

24.250  -25.310 

-7.*"* 

-O.O70  -7 . 4 c 0 7.500 

_o.o7r  -7.550 

-5 . c jo 

-31.250  -7.5C0 

~ -5,500  -31.250“ 

CC(IT  PPM  u 

TP 

5 

4 

7.*r? 

5«p 

-?1.7r0  -7.500 

7,->o0  _73.9F«\ 

.250 

- ’1  .2  50  -7.5CO 

“ 7 . 2 0 0 -29.95C 

Xn=  rrp'Tro 

r>r  tmppttlc 

6 

6 

-12. 4®0 

T 7 , ° 4 4 _7->,447  -12. Pf 

12.P64 

-22.652  -13.C23 

12.895  -22.665 

— 1 ’ • 3 ° ’ 

12.046  -27.407  -i?.3?7 

12.015 

-72.717  -13.471 

13.1C3  -22.754 

TOP  re »j re? 

PC  T 140  n T T l P 

7 

6 

-17. FQP 

1 1.°54  -77.447  -13.471 

12.103 

-22.7=4  -17,596 

13.2-7-22.799 

-l’.7"* 

1 7 . ? 2 5 -”.J45  -13.795 

12. 4;5 

-27.905  -1’.666 

13.596  -22.965 

tob  r=»'T  = o 

rr  TMOPTTl s 

P 

6 

-1  2.*°0 

12.0=4  -77.447  -13.P66 

12.596 

-22.965  -13.916 

13.743  -?7.0’9 

-13. O44 

13,004  —7  7,  OQ  4 -!?.t;40 

1= .051 

-22.160  -13.032 

14.2C5  -23.226 

TO0  rrvfcp 

pp  THPPTT1.C 

<3 

6 

-1  ?.4c=, 

17.0=4  -77.447  -13.032 

1 4 . 20  5 

-23. ??6  -13. ?9? 

14.355  -73.791 

-17.P” 

1 4 . 4 C Q -77.7  = 7 —13.75? 

14.675 

-22.411  -13.652 

14.76m  -23.464 

TOP  r cp  Tee 

PC  TMOPTTl p 

1C 

6 

-12. AO" 

17.0  = 4 — 7 7 , = 4 7 -13. F5? 

14.760 

-23. 464  -33.535 

14.671  -23.51? 

-) ? . 

1 4 . P 4 7 —77.0=  7 -1 7 . 2 5 R 

1* .046 

-22.567  -13.103 

15.1C6  - ? 7 , 6 3 ’ 

T q p rrvTco 

PC  TWOPTTl P 

11 

6 

-32.  *<3 5 

17.0=4  —77.447  -13.103 

if. ice 

-23.61?  -12.941 

15.147  -73.670 

-17.7-t, 

1 1 • 3 F 7 -77.470  -12.604 

15.167 

-23.639  -37.420 

15.147  -23.620 

X0P  rcuTfo 

pp  two pj Tl  c • 

12 

6 

-■*7.490 

17,0  = 4 -77.447  -12. 43<5 

15.147 

-73. F?i  -12.277 

1 5 . 1 CF  - 2 3 • 6 1 3 ~ 

-32.177 

1 « .046  -? ’ . 5 F 7 -n  .077 

1 4 . °6  7 

-23.5  5?  -H.P45 

14. =71  -27.512 

TOP  rev tee 

PC  TMPPTTt  C 

13 

6 

17.0=4  -77.447  -11 . 04= 

1 4 • P7 1 

-23.512  -11.726 

14.760  -23.464 

-13 .62° 

14.47=  -77.411  -11.547 

34.499 

-23.353  -11.467 

14.355  -23.291 

T0°  d c »' T c o 

pc  t mo  pt  T ( P 

14 

6 

-3  ?. * on 

’7.0  = 4 -27.447  — 3 1 . 4 R 7 

1 4 . ? 5 5 

-22.291  -31.446 

14.2C5  -23. 276 

-M.*’l 

14.051  -77.160  -11.43* 

12.696 

-23 .094  -11.464 

13.743  -23.029 

top  r = *'T=p 

pc  tmpptTLP 

15 

6 

— 7 2 • f op 

17.0=4  -2 7.447  -11.464“ 

12.743 

-23.029  -11.534 

13“.596“-22.965_ 

-n.f°  5 

13.455  -7 ? • °05  -11.676 

13.325 

-22 . 0 4 9 -11.7P4 

13.2C7  -22.799 

top  r f mt  = p 

PC  JMOPTTl C 

3 6 

6 

" -1 ?.FP0 

7 7.0  = 4 -73,447  -11.7«4 

17.207 

-22.799  -13.909 

1 3 . 1 03  -22 , 754~ 

-l?.r,tq 

17.014  -22.717  -12.19R 

12.946 

-22.0R7  -12.357 

12.895  -22.665 

TOP  Ce*T« 

PC  TMOPTTI.P 

17 

4 

" — 1 7 . F ®3 
-12.60} 

17.0=4  -77.447  -12.3=7 
17.0=4  -77.447 

12 • p95 

-22.665  -12.522 

12.e64^22.652 

» 

1 


1 ^ . - 

SEAT  PAN 

I ect  CU9 

18 

6 

-7. 2*9 

7,’pfl  -?o . 9 * 0 

-?.5nO 

7.260 

-29.95o 

-2.750 

7.280  -29.4*0 

-1.499 
SFAT  pan 

7 . 7 PO  -’O.O50 

LEFT  eyi 

-4.500 

7.280 

14 

-20.95C 

6 

-5.500 

7 , 2 p0  -24.9*0 

-2.7*9 

7. ’Of)  -73,9*0 

-5.500 

7 . 2 dC 

-29.950 

-6.5C0 

7.2E0  -74.450 

-7.499 

7.703  —7O.Q50 

-7.500 

33.710 

-24.13C 

-5.500 

11.710  -29. I’C 

■ 

SEAT  pan 

l eft  eWp 

2 C 

6 

-2.’?o 

7,’°0  -’9.959 

-6.500 

11.710 

-29.130 

-5.500 

11.710  -29.130 

I *4. 

-4.590 

11.730  -’Q.1’0 

-3 , 5oO 

11.710 

-24.130 

-2.250 

11.710  -29.130 

|4oi c n»»e  , 

TAPLr  *'A"C  « /-rNTPniA’F 

TH7'  SCT  TC  r*T*  rnvjrTTT^  CF  A roCKrIT  CONTPCL  CODE  OTCTIONAPY,  WTTM  CONTPCL 
COPF  NAMc?  »Mf>  rqk-ToPL  O^OE  CCQOOINATES  IN  THF  Fp  P CDOPPINATE  SYSTEP 
FOB  TUC  ay-  p t L nT  ftattov  WTTM  2 FUFOIVICEO  PLANES 

27  

FJB4PMT  -5. *10  ’7.204  -11.410  ] 

rpccpnoi^c  -7,o«n  ”.C^P  -32.329  1 

FIAPCE{mtp  -7.709  ’5.2tjfl  -7C.419  ? 

FIATP'PEEn  -4.39)  . 5 3 7 -19.245  ? 

FIAITT*TS  -4.p°9  25 . 2 ? 9 -3  5.039  2 

FIAvri jTi«  -7.709  ’6.357  -15.3el  Z _ _ 

c jo«-c»t.ptp  -11. ’40  ’=.195  -29.P59  2 

fjtTruviPT  -4. ”9  ’4,03*  -22.162  2 

p I V e o t \i  c I -7.703  7f.8C7  -37.973  2 

FUrl OHAMT  -7.209  ’4 . 6 P2  -23.275  2 

A«PTP»’llv9T  -10.009  ’P.pjo  -17.729  2 

wSAP-ftat  -11.740  26.243  -15.919  2 _ 

U S * A l V 7 -H.l’A  74.705  -73.1&6  2 

VSrcijCTT  -19.440  74.735  -IP. 316  2 

AC*r4'l  -.’39  ’6.519  -14.flP  ’ 

A C A l 0 L 1 . ’49  24.53  9 -14 .f 1 H 3 

ACA«r  -’.119  26.519  -14.618  ’ 

P I A 0 1 -.’30  25.P74  -3  7.660  3 

F I A 9 T c T 1.63  9 74.44C  -10.705  3 

FI^fy  -.’10  24.771  -22.P45  3 

IF7FT17  -’4.CA3  -16.600  , COO  -C 

4cT"TprtP  .009  ]00  -P.5C0  -C 

4FTDTCT  76.009  —16.6  iju  -13C.40C  -0 

NUTPIFPO  .900  -5.500  -31.75C  -0 

Tpppnuv  .991  -4.0^  -33.160  -C 

SPPHP  .000  -4.4C0  -’P.390  -0 

FCtm’Ti tu"  —3  2.4Q9  15.161  -23.636  -0  _ 

TA  °l  r M A “ f • 

TAP|P  V*«p  • P9NPUAPA7C 

I H T 4 9ATA  FFT  THE  NAMES  CF  CHNTPPL  SHAPF*  AN9  COCKPIT  CP  J EC  T F ANC 

TMETP  r00BCSP9NDTN9  PLANE  CFSIGNATION  NUMBFPS  USING  LOWfP  ant  L'PPFF  POUNDS 

1 

PILOT  PANEL*"  1 3 

PILOT  SEAT  4 5 

PLAN-ec  VT*M  many  ® OUN 9 a p Y PTS  6 20 

TA°LF  name  . - _ 


ENO  C*F£S/ 


P 
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APPENDIX  E:  INPUT  VARIABLES  FOR  CGE  REACH  BASKET  MODEL 


CARD  INPUT  VARIABLE  FORMAT 

1 (TITLE( I ) , 1=1 ,8)  8A10 

2 NCALL, I SKIP, IP, IP0SE,  2014 

NSTEPS.LI ,LM 


3 IC0NST,  NMJ,  NMJUT  2014 


4 IA, IB, IC, ID , IE, IJ0IN,  2014 
IUB,NUB,MUB 


DESCRIPTION 


80-character  title 

Use  the  values  2,  1 , 0,  1 , 
100,  blank,  blank.  If 
optimization  output  is  to 
be  desired,  use  IP=9 
(partial)  or  IP=4  (full). 

LI  and  LM  have  defaults. 

IC0NST  = 2*LE  (see  below). 
NMJ  = total  number  of 
moveable  links  used. 

NMJUT  = NMJ  for  upper  body 
reach  analysis. 

IUB  = number  of  links 
(including  rigid  links)  in 
spine/right  arm  and  also 
in  spine/left  arm  systems. 
NUB  = number  of  links  in 
spine  and  head.  MUB  = 
number  of  links  in  each 
leg. 

IA  = ISPRA(iUB)  (see  below) 
IB  = I LA ( IUB) 

IC  = IH(NUB) 

ID  = IRL(MUB) 

IE  = ILL (MUB) 

IJ0IN  = ISPRA  index  of  the 
last  spine  link  (usually  = 
2). 


E-l 


S3"  f 


r 

‘\ 


\ 


V>\J^ 


1 


CARD 

5 


6 


7 


8 


9 


INPUT  VARIABLE 


LA,LB,LC,'lD,LE 


( IDVAN(I) ,1=1 ,13) 


A(J-I),  B(J-l), 
A(J),  B(J) 

PA(J-l),  PB(J-l), 
PA(J),  PB(J) 

(Actually,  16  cards 
are  read) 


LJ0IN , ( IQ(L ) , L=1  ,LC) , 
( IPAR(L) , L=1 ,LC) 


FORMAT 

2014 


2014 


4F10.1 


2014 


DESCRIPTION 


LA  = number  of  variable 
angles  in  spine/right  arm. 
LB  = LA  + number  of  varia- 
ble angles  in  left  arm. 

LC  = LB  + variable  head 
angl es . 

LD  = LC  + right  leg  angles. 
LE  = LD  + left  leg  angles. 

Systems  using  varying  angu- 
lar limits,  in  the  order: 
thorax(=l ) , neck(=2) , 
clavicle(=3),  shoulder, 
wrist,  eye,  hip,  foot. 

Repeat  cards  7 and  8 for 
1=1 , . .. , 8,  with  J=2*I. 

The  angular  limit  values 
for  0 =0,  90,  180  and  270 
degrees  in  the  local  system 
are  read  from  card  7.  Card 
8 has  correspondi ng  "pre- 
ferred" angles,  which  are 
not  used  in  the  RBA  model. 


LJ0IN  = number  of  variable 
spine  angles. 

I Q ( L ) = index  in  ISPRA, 

I LA,  IH,  IRL  or  ILL  of  the 
link  to  which  angle  L belongs. 
IPAR(L)  = 1 , 2,  or  3, 
depending  on  which  degree 
of  freedom  angle  L repre- 
sents. If  IPAR(L)  = 1, 

L is  a 0 (bend)  angle. 

If  IPAR(L)  = 2,  L is  a 4> 
(direction  of  bend)  angle. 


E-2 


CARD 


INPUT  VARIABLE 


FORMAT 


DESCRIPTION 


13 


(Conti nued) 

If  IPAR(L)  = 3,  L is  a 
(twist)  angle. 


10 

( I Q ( L ) ,L=LC+1 ,LE) , 
(IPAR(L) ,L=LC+1  ,LE) 

2014 

The  information  correspond- 
ing to  card  9 for  the  leg 
system  Euler  angle  varia- 
bles. 

11 

(ISPRA(I) ,1=1 , IUB) 

2014 

Spine/right  arm  system 
indices,  beginning  with 
bottom  of  spine. 

12 

( ILA( I ) ,1=1 , IUB) 

2014 

Spine/left  arm  system 
indices. 

13 

( IH( I) , 1=1 ,NUB) 

2014 

Spine/head  system  indices. 

14 

( IRL ( I ) , 1=1 ,MUB) 

2014 

Right  leg  system  indices. 

15 

( I LL ( I ) , 1=1 ,MUB) 

2014 

Left  leg  system  indices. 

16 

(C0NST(L) ,L=1 , ICP ) 

8F10.0 

ICP  = IC0NST  + 10.  Several 
blank  cards  for  the  RBA 
model . 

17 

(C0N( K) , K=1 , IC0N) 

8F10.0 

IC0N  = 3*MMJ  - LE.  These 

are  values  for  Euler  angles 
which  remain  fixed  in 
systems  having  1 or  2 of 
the  possible  3 degrees  of 
freedom.  The  order  is: 
e,  4> , , for  the  spine, 

right  arm,  left  arm,  head, 
right  leg,  and  left  leg. 


MATRIX 


14 


Set  to  zero  (0). 
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— . 


J 


CARD 


19 


20 


21 


22 


23 


24 


25 


26 


27 


28 


29 


INPUT  VARIABLE 

FORMAT 

DESCRIPTION 

(TRNSLT( ISPRA( I ) ) , 
1=1,  IUB) 

8F10.0 

Spine/right  arm  link  lengths 

THET, PHI , PS I 
Several  cards  possi- 
ble. 

3F10.0 

Euler  angle  values  for  each 
fixed  link  in  the  spine/ 
right  arm  systems. 

(TRNSLT( I LA ( I) ) , 
I = IJ0IN+1 .IUB) 

8F10.0 

Left  arm  link  lengths. 

THET, PHI ,PSI 

3F10.0 

Euler  angles  for  fixed 
1 inks. 

(TRNSLT(IH(I)), 

I = IJ0I N+l , NUB) 

3F10.0 

Head  link  lengths. 

THET,  PHI, PSI 

3F10.0 

Euler  angles  for  fixed 
links. 

(TRNSLT ( IRL ( I ) ) , 
1=1,  MUB) 

8F10.0 

Right  leg  link  lengths. 

THET, PHI, PSI 

3F10.0 

Euler  angles  for  fixed 
1 i nks. 

(TRNSLT( ILL ( I ) ) ), 
1=1,  MUB) 

8F10.0 

Left  leg  link  lengths. 

THET, PHI, PSI 

3F10.0 

Euler  angles  for  fixed 
1 inks. 

(BL(L),BU(L),L=1,LE) 

8F10.0 

Fixed  lower/upper  limits 
for  variable  Euler  angles 
(initial  values). 

8F10.0 


E-4 


30 


(w(l) ,l=i ,le) 


Initial  values  for  all 
variable  Euler  angles. 


CARD 

INPUT  VARIABLE 

FORMAT 

DESCRIPTION 

31 

(PTI(I), 1=1,30) 

8F10.0 

For  RBA,  4 blank  cards. 

32 

MIHHP.MIMH0 ,MIML0S, 
M I MT  0S , M I M F P , M I M F 0 

2014 

For  RBA,  use  the  values  2, 
0,  0,  0,  0,  0. 

33 

MFMHP ,MFMH0 , MFML0S , 
MFMT0S ,MFMFP , MFMF0 

2014 

Same  as  card  32. 

34 

ERR, ERC, SCALE 

8F10.0 

Use  the  values  .0001,  .05, 
.50. 

35 

(PTF(I), 1=1,30) 

8F10.0 

For  RBA,  4 blank  cards. 

36 

IRBASA 

14 

Use  zero  (=0). 

37 

DELZ.ZER0, DELTH, DIS, 
IA1 , IA2.NLEV 

4F10.0, 

314 

DELZ  = spacing  between 
reach  planes  (use  nega- 

tive  value  to  start  with 
top  plane). 

ZER0  = height  of  initial 
reach  plane  (bottom  of 
spine  coordinates). 

DELTH  = reach  ray  azimuth 
increment. 

DIS  = value  slightly  out- 
side reach  capability 
(estimated)  measured  from 
vertical  bar  through  bottom 
of  spine. 

IA1.IA2  = initial  and  final 
reach  rays.  Ray  1 starts 
with  azimuth  = 0 degrees 
(to  the  right  of  the  human 
operator). 

NLEV  = number  of  horizontal 
reach  planes. 


APPENDIX  F:  COMPREHENSIVE  ANNOTATED  LIST  OF  MAIN  PROGRAMS  AND  SUBROUTINES 


PROGRAM 

ANPL0T 

ANPL0T 

C0RPHI 

HMA1 


MAN2 


MAN  2 A 
(MAN3) 


UPDATE 
DECK  NAME 

ANPL0T1 

ANPL0T2 

C0RPHI 

HMA1 


fJlAN2 


MAN2PCH 

ENM2PC 

MAN2PRG 

MANAPCH 

END2APC 

MANAPRG 

MAN2A 


IN  MMDLIB , WITH  UPDATE  DECK  NAMES 
MAIN  PROGRAMS 
DESCR I PT I ON 


Outputs  plot  tape  for  link-system  Euler  angles  at  each 
motion  step.  Input  link-system  joints  at  each  step. 

Deck  includes  subroutines  MPL0T,  START1 . 

Different  version  - same  description  applies. 

Converts  HMA1  output  by  changing  signs  of  some  angles. 

Punch  output.  ,, 

Human  subject  motion  analysis.  Uses  data  from  Phase 
II  man-model  validation.  Input  locations  of  certain 
arm/torso  points  (from  tape-marks  on  motion  picture 
frames  of  motion),  calculate  angles  and  link  lengths 
at  each  motion  step  in  accordance  with  a simplified 
spine/clavicle  model. 

The  basic  Phase  II  man-model  main  program,  and  from 
which  the  Phase  II  BGE  Motion  Model  overlay  and  the 
Phase  III  Reach  Basket  Analysis  program  are  derived. 

The  MAN2  deck  does  not  include  the  PR0GRAM  header 
card.  Two  different  versions  of  the  PR0GRAM  card  are 
in  decks  MAN2PCH  and  MAN2PRG. 

PR0GRAM  statement  containing  PUNCH  in  parameter  list 
to  get  punched  output  from  MAN2. 

END  card  to  follow  MAN2PCH  - included  solely  as  a 
means  of  compiling  all  decks  on  the  library  in  one 
compilation. 

PR0GRAM  statement  normally  used  with  Phase  II  BGE  or 
Phase  III  Reach  Basket  versions  of  MAN2. 

PR0GRAM  MAN2A  statement  for  MAN2A  (same  as  MAN3), 
the  Phase  II-A  (Phase  III)  man-model  with  separate 
body  system  optimization.  This  PR0GRAM  statement  is 
for  a version  with  punch  card  output. 


END  card  to  follow  MANAPCH  - included  solely  as  a 
means  of  compiling  all  decks  on  the  library  in  one 
compilation. 


PR0"RAM  statement  normally  used  with  Phase  III  BGE 
version  of  MAN2A  (MAN2A  has  been  renamed  MAN3,  but 
the  UPDATE  decks  do  not  reflect  this  as  yet). 


The  Phase  III  man-model  main  program.  See  MAN2 
description  for  similar  information  relating  to  deck 
structure  using  different  PR0GRAM  call  cards. 


' "4PS  BLANiC.NCT 


MAIN  PROGRAMS 


UPDATE 

PROGRAM  DECK  NAME  DESCRIPTION 

p 

TNLPS  TANELPS  Main  program  of  tangent  planes  package  for  body  segment 

wrap-around  planes.  This  package  is  mostly  contained 
within  deck  TANELPS.  It  calculates  vertices  for 
circumscribing  an  ellipse  with  a polygon  so  as  to 
minimize  the  difference  between  ellipse  cross-sectional 
area  and  polygon  cross-sectional  area.  The  minimiza- 
tion presents  a constrained  minimization  problem,  and 
so  a version  of  the  LYNX  package  (deck  LYNXLPL)  is 
used  along  with  the  TANELPS  package. 

TLYNX  TLYNX  Test  program  for  nonlinear  constrained  minimization 

subroutine  LYNX.  It  calls  LYNX  with  either  of  two 
objective  function/penalty  function  subroutine 
packages.  These  are  the  FUN1-FUN1X/PEN1-PEN1X  and 
the  FUN2-FUN2X/PEN2-PEN2X  packages.  In  this  way, 
two  different  optimization  problems  can  be  run  in  a 
single  computer  run  to  test  LYNX. 

TRACE  TRACE  Provides  a joint- trajectory  analysis.  Input  vertices 

along  a stepwise-determined  trajectory.  Data  can  be 
from  either  human  subject  motion  or  a man-model  run 
on  the  computer. 


SUBROUTINES 


UPDATE 
DECK  NAME 


DESCRIPTION 


BADGER 


B0XEAR 


C0NVRID 


C0NVRT 


C0NVVJL 


CR0SS 


Unconstrained  minimization  using  a stripped-down 
earlier  version  of  LYNX.  (The  Numerical  Analysis 
organization  can  supply  more  up-to-date  codes  for 
unconstrained  minimization  which  should  be  more 
efficient  and  do  use  less  storage.) 

Solves  for  Euler  angles  0 and  <J>  given  3 joint  loca- 
tions defining  2 adjacent  links.  Used  in  human 
subject  motion  analysis,  among  other  things. 

Dummy  version. 

BGE  version  (compatible  with  INTRAN  link  structure 
definitions).  Entry  points  to  (a)  input  body 
segment  solids  in  local  (body  segment)  coordinate 
systems,  not  scaled  to  size,  and  (b)  rotate  and 
translate  local  body  segments  into  position  using 
Euler  angles  and  link  lengths  describing  link- 
system  position.  Body  segments  are  also  scaled  up 
to  link-length  size. 

Used  with  statistical  validation  (VAL)  version  of 
man-model.  Does  not  actually  supply  body  segments, 
but  performs  needed  calculations  for  statistical 
validation. 

Calculates  vertices  of  a partition  of  a 3-dimensional 
rectangular  box  into  cubes. 

Called  from  entry  points  B0DZ  and  B0DW  of  B0DX  to 
perform  actual  transformations  to  scale  up  and 
position  the  surface  plane  segments  defining  a solid 
body  segment. 

Identity  transformation  to  replace  C0NVRT  when  no 
angular  constraints  are  being  used. 

Fixed  (FJAL)  or  Discrete  Variable  (DVJAL)  angular 
Limits  version.  Inverts  the  GMAP  transformation  to 
get  free  parameters  from  a given  set  of  Euler  angles 
with  given  lower  and  upper  bounds. 

Version  to  invert  the  GMAP  transformation  to  get  free 
parameters  from  given  Euler  angles  with  given  lower 
and  upper  bounds  which  vary  continuously  (VJAL 
versi on) . 

Three-space  vector  cross  product.  Supplies  all 
relevant  information,  including  vector  norms,  unit 
normal  vector,  and  sine  of  included  angle. 


SUBROUTINES 


SUB- 

ROUTINE 

UPDATE 
DECK  NAME 

DESCRIPTION 

CTERP 

BADGER 

Cubic  interpolation  subroutine  for  BADGER. 

CTERP 

CTERP 

Cubic  interpolation  subroutine  for  LYNX. 

CTERP 

LYNXLPL 

Cubic  interpolation  for  Long  Parameter  List  (LPL) 
version  of  LYNX. 

ELIPSE 

TANELPS 

Part  of  TANELPS  package. 

EVALO 

EVAABGE 

Man-model  environment  subroutine  for  MAN3  BGE  version. 
Certain  statements  (documented  in  code)  must  be 
removed  before  running  as  a BGE  overlay,  and  calls  to 
INJECT  and  RYTE  should  be  removed  or  dumrny  versions 
of  these  two  I/O  routines  supplied.  The  EVAABGE 
version  as  is  will  run  MAN2A(MAN3)  independently  by 
calling  for  I/O  and  setting  certain  parameters, 
thereby  taking  the  place  of  INTRAN  and  0UTG0  of  the 
BGE  system. 

EVALO 

EVAAVAL 

Man-model  environment  for  MAN3  statistical  validation. 

EVALO 

EVALBGE 

Man-model  environment  for  MAN2  in  the  BGE.  However, 
see  the  EVAABGE  description  for  important  information. 
As  is,  this  version  will  run  MAN2  as  an  independent 
system  with  its  own  I/O. 

EVALO 

EVALRBA 

Man-model  environment  for  the  MAN2  Reach  Basket 
Analysis  package. 

FTERP 

BADGER 

Fibonacci  interpolation  for  BADGER. 

FTERP 

FTEREXP 

Fibonacci  interpolation  for  experimental  (EXP)  version 
of  LYNX. 

FTERP 

FTERP 

Fibonacci  interpolation  for  LYNX. 

FTERP 

LYNXLPL 

Fibonacci  interpolation  for  Long  Parameter  List  (LBL) 
version  of  LYNX. 

FUN1 , 
FUN1 X 

N0RMXSQ 

Test  objective  function  for  LYNX.  Squared  Euclidean 
norm  of  X. 

FUN1 , 
FUN1X 

TANELPS 

Objective  function  (cross-sectional  area  difference) 
for  TANELPS  package. 

FUH2 , 
FUN2X 

ZER0 

Identically  zero  objective  function  for  LYNX. 

T-4 


SUBROUTINES 


SUB-  UPDATE 


ROUTINE 

DECK  NAME 

DESCRIPTION 

GMAP 

GMAP 

Transforms  optimization  free-parameters  to  box- 
constrained  Euler  angles  to  remove  the  Euler  angle 
box  constraints  from  the  LYNX  optimization. 

GMAP 

GMAP ID 

Version  of  GMAP  which  is  the  identity  (transforms 
angles  to  angles,  straight  across). 

GMAP 

GMAPVJL 

Continuously  varying  Angular  Limits  (VJAL)  version 
of  GMAP. 

HBAD 

BADGER 

Called  by  BADGER  to  operate  on  H matrix. 

HID 

HID 

Sets  N x N matrix  to  the  identity. 

HID 

HIDCMP 

C0MPASS  version  of  HID. 

INJECT 

INJACT 

Input  subroutine  for  MAN3  BGE  version  when  run 
independently  of  the  BGE  system. 

INJECT 

INJAVAL 

Input  subroutine  for  statistical  validation  (VAL) 
version  of  MAN3  package. 

INJECT 

INJECT 

Input  subroutine  for  MAN2  (any  version)  when  run 
independently  of  the  BGE  system. 

LEG, 

LEGX 

LEG 

Calculate  constraint  residuals  for  the  leg  systems 
during  an  optimization  to  solve  for  leg  positioning 
Euler  angles. 

LIMP 

LIMP 

Sets  up  linear  programming  problem  for  spine  system 
interpolation  in  MAN3  with  separate  body  systems 
optimization. 

LINE 

LINE 

One-dimensional  linear  interpolation  between  two 
points  in  N-space. 

LINE 

LINECMP 

C0MPASS  version  of  LINE. 

L(9S, 

L0SX 

L0S 

Calculate  constraint  residuals  for  line-of-sight 
viewing  constraint  during  an  optimization  in  which 
body  positioning  Euler  angles  are  to  be  found. 

LYNX 

LYNXEXP 

Experimental  version  of  optimization  subroutine  LYNX. 

LYNX 

LYNXLPL 

Long  Parameter  List  version  of  optimization  sub- 
routine LYNX.  It  is  much  slower  than  LYNXVIP  and  its 
use  is  not  recommended. 

F-5 


SUBROUTINES 


SUB- 

ROUTINE 

UPDATE 
DECK  NAME 

DESCRIPTION 

LYNX 

LYNX0LD 

Prior  version  of  optimization  subroutine  LYNX.  Use 
is  not  recommended. 

LYNX 

LYNXVIP 

Currently  used  version  of  optimization  subroutine 
LYNX,  which  uses  the  Davidon  Fletcher-Powell  method 
with  penalty  function  to  minimize  a differentiable 
nonlinear  function  of  several  variables,  subject  to 
nonlinear  constraints  on  the  variables.  System  routi 
VIP  is  called  for  inner  products. 

MAB 

MAB 

Multiply  two  matrices.  Entry  points  for  product  of 
matrix  times  transpose  of  other  matrix. 

MAB 

MABVIP 

Version  of  MAB  which  calls  system  routine  VIP  for 
row-column  products. 

MAB, 

MABT, 

MATB 

BADGER 

In  the  BADGER  version,  the  entry  points  to  MAB  are 
all  separate  subroutines,  otherwise  the  code  is  the 
same  as  in  the  MAB  deck. 

MATINV 

MATINV 

Matrix  inversion  by  Gaussian  elimination  with  row 

pivoting.  It  is  suggested  that  if  a matrix  inverse 
is  ever  needed,  subroutine  INVERS  (on  the  EKS- 
MAINSTREAM  subroutine  library)  be  used.  MATINV  is 
not  used  in  MMDLIB,  and  should  be  eliminated. 


MPL0T 

ANPL0T1 , 
ANPL0T2 

Called  by  program  ANPL0T. 

PARAM 

PARAM 

Called  from  output  subroutine  RYTE  for  formatted 
output  of  link-system  Euler  angles  with  associated 
information  (lower  and  upper  bounds,  etc.). 

PENLTY 

PENLTY 

Performs  penalty  function  calculation  for  LYNX,  with 
simple  box  constraints  on  the  optimization  variables 
(e.g. , Euler  angles). 

PENLTY 

PENLVJL 

VJAL  version  of  PENLTY. 

PENLTY 

PENL0.00 

Version  of  PENLTY  for  no  box  constraints  on  the 
optimization  variables- (e.g. , in  certain  optimization 
test  problems). 

PEN1  , 
PEN1X 

SNMIN1 

Constraint  residuals  and  their  gradients  for  optimi- 
zation test  problems  with  a sum-of-squares  equality 
constraint. 

SUBROUTINES 

SUB- 

ROUTINE 

UPDATE 
DECK  NAME 

DESCRIPTION 

PEN2, 

PEM2X 

PLANES 

Constraint  residuals  and  their  gradients  for  optimi- 
zation test  problems  with  linear  equality  constraints 

PEN1  , 
PEN1X 

TAN EL PS 

Constraint  residuals  and  their  gradients  for  calcu- 
lating body  segment  cross-sections  in  TANELPS 
package. 

PIV0T 

PIV0T 

Called  by  SYMB0L  to  perform  pivoting. 

P0C, 

P0CX 

P0C 

Constraint  residuals  and  their  gradients  for  optimi- 
zation on  arm  or  leg  systems  when  MAN3  version  is 

used  for  man-model . 

P0C, 

P0CX 

P0CEXP 

Experimental  version  of  P0C,  P0CX. 

P0CL0S, 

P0CL0X 

P0CLEXP 

Experimental  version  of  P0CL0S,  P0CL0X. 

P0CL0S, 

P0CL0X 

P0CL0S 

Constraint  residuals  and  their  gradients  for  optimi- 
zation on  arm  and  head  system  in  total  or  partial 
upper  body  positioning  when  MAN2  version  is  used  for 
man-model . 

P0CL0S, 

P0CL0X 

P0CLRBA 

RBA  version  of  P0CL0S,  P0CL0X. 

P0SE 

P0SA 

Positioning  1 ink-system  when  Euler  angles  and  link 
lengths  are  provided.  P0SE  provides  the  ability  to 
position  the  man-model  link-system  whenever  it  is 
desired  to  do  so  without  calling  the  optimization 
package.  The  P0SA  deck  is  the  MAN 3 version. 

P0SE 

P0SE 

The  MAN2  version  of  P0SE. 

PREFAN 

PREFAN 

Varies  the  "preferred"  Euler  angles  in  the  objective 
function  SPRING  during  an  optimization  in  the  VJAL 
version  of  the  man-model.  Can  be  used  with  either 
MAN2  or  MAN3  versions. 

PREFAN 

PRENULL 

Dumniy  version  for  use  with  fixed  (FJAL)  or  discrete 
variable  (DVJAL)  versions. 

PREP 

PREP 

Sets  up  VJAL  storage  for  GMAP. 
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SUBROUTINES 


; 


SUB- 

ROUTINE 

UPDATE 
DECK  NAME 

DESCRIPTION 

RAKE 

BADGER 

BADGER  version  of  RAKE. 

RAKE 

RAKE 

Used  by  LYNX  to  call  objective  function  and  constraints 
during  an  optimization. 

RAKE 

RAKEVJL 

VJAL  version. 

RAKE 

RAKEOOO 

NJAL  version  (n£  angular  limits). 

REDUCE 

REDUCMP 

Gaussian  reduction  for  SYMB0L  (C0MPASS). 

REPLCE 

BADGER 

BADGER  version  of  REPLCE. 

REPLCE 

REPLCE 

Advances  Davidon  minimization  progress  in  LYNX  by 
storing  current  best  solution. 

REPLCE 

REPLCMP 

C0MPASS  version. 

R0T3 

R0T3 

Store  3x3  rotation  matrix  and  its  derivatives  when 
Euler  angle  sines  and  cosines  are  input. 

R0T3T 

R0T3T 

Transpose  of  R0T3  matrix  is  stored. 

R03 

R03 

Stores  3x3  rotation  matrix  when  Euler  angles  are 
input. 

RP 

RP 

Accumulates  product  of  rotations. 

RYTE 

RYTA 

Man-model  output  routine  for  MAN3  version. 

RYTE 

RYTAVAL 

Statistical  validation  (VAL)  version  of  man-model 
output  (MAN3  version). 

RYTE 

RYTE 

Man-model  output  for  MAN2  version. 

SCALAR 

SCALAR 

Multiply  vector  times  a scalar. 

SCALAR 

SCALCMP 

C0MPASS  version  of  SCALAR. 

SPINE 

SPINE 

Spine  interpolation  main  subroutine  for  MAN3  version. 

SPINE 

SPINRED 

Simply  reads  and  stores  spine  angles  which  are  input. 
Used  in  statistical  validation. 

SPRING, 

SPRINX 

SPRINGO 

F(X)  = 0 objective  function  and  gradient.  Calls  GMAP 
to  set  up  Euler  angles  even  though  F is  0. 

F-8 


SUBROUTINES 


SUB- 

ROUTINE 

UPDATE 
DECK  NAME 

DESCRIPTION 

SPRING, 

SPRINX 

SPRING1 

Weighted  sum-of-squares  objective  function  and 
gradient.  Weights  and  preferred  angles  are  fixed 
during  optimization  (FJAL  version). 

SPRING, 

SPRINX 

SPRING2 

Same  as  SPRING1  version  except  some  weights  vary 
(the  weight  for  each  Q Euler  angle  depends  on  the 
associated  4>  Euler  angle  of  a rotation  triple 
(Q  , $ , ) (FJAL  version). 

SPRING, 

SPRINX 

SPRING7 

Weighted  sum-of-squares  for  VJAL  version.  The  $ 
angle  is  not  included  as  a separate  term  in  the  sum- 
of-squares  . 

SPRING, 

SPRINX 

SPRING8 

Same  as  SPRING!  deck  but  with  a different  storage 
scheme  (DVJAL  version). 

SPRING, 

SPRINX 

SPRINIO 

Same  as  SPRING2  deck  but  with  a different  storage 
scheme  (DVJAL  version). 

START1 

ANPL0T1 

Called  by  ANPL0T. 

START1 

ANPL0T2 

ANPL0T2  version. 

SYMB0L 

SYMB0L 

Linear  programming  subroutine  for  spine  model.  Also 
used  by  BGE  overlays  other  than  motion  model. 

TAN16 

TANELPS 

Part  of  TANELPS  package. 

TASK! 

TASA 

Body  system/task  execution  sequencing  logic  for  MAN3 
version  of  motion  model. 

TASK1 

TASK 

Logic  for  MAN 2 version  of  motion  model. 

TRAC 

BADGER 

BADGER  version  of  TRAC. 

TRAC 

TRAC 

Output  subroutine  for  LYNX. 

TRANS F 

TRAN0LD 

Old  version  of  TRANSF.  Use  not  recommended  (slow). 

TRANSF 

TRANVIP 

Current  best  version  of  TRANSF.  TRANSF  is  the  true 
heart  of  the  variable  link-system  model.  The 
current  set  of  Euler  angles  for  the  link  system, 
together  with  the  fixed  link-lengths  and  the  link- 
system  tree  structure  logic,  are  used  to  calculate 
the  positions  of  the  link-system  joints.  TRANSF  is 
called  once  for  each  branch  of  the  tree,  and  accepts 
accumulated  rotations/transl ations  to  connect  the 
current  branch  with  the  branch  to  which  it  is  attached. 
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SUBROUTINES 


ft. 


SUB- 

ROUTINE 

UPDATE 
DECK  NAME 

DESCRIPTION 

TWIST 

TWIST 

Finds  the  twist  ( \|)  ) angle  given  two  joined  links 
plus  a point  which  rotates  with  and  is  external  to 
one  of  the  links. 

VARBA 

VARBA 

Recalculates  angular  limits  between  optimizations 
for  DVJAL  version. 

VARBA 

VARNULL 

Dumrny  version  for  use  with  other  than  DVJAL  versions 
of  motion  model . 

VT0X 

LYNXLPL 

Used  in  place  of  REPLCE  in  long  parameter  list  (LPL) 
version  of  LYNX. 

WRAP4 

WRAP4 

Sets  up  body  segment  solids  to  be  stored  and  later 
rotated/translated  into  position  along  the  link 
structure  in  scaled  up  form. 

WRITBS 

WRITBS 

Optional  output  from  body  segments  package  (B0DX). 

WWRAP 

WWRAP 

Optional  output  from  B0DX  following  WRAP4  execution. 
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APPENDTX  G:  DMS/CGE  INTERFACE  MODULE  SAMPLE  PROBLEM 


COMPUTER  AIDED  FUNCTION-- ALLOCATION  EVALUATION  SYSTFM 


BEGIN  CAFES-CREATE  NEW  DATA  BANK/ 

BEGIN  DATA  BANK  EDITOR/ 

CGE INPUT • A7£  / 

COCKPIT  PLANE S* PLANES  ONE  AND  TWO/ 

NAME-PLANE1/ 

NUMBER  * 1 / 

VERTICES-1. 0,1. 0,1. 0.2. 0*2. 0,2. 0,2.0, l.C,0./ 

NAME*PLANE2/ 

NUMBER *2/ 

VEPTICES-0.,0.,2.0,0.,1.,1./ 

CCNTROLS-CCNTROLS  ONE  AND  TWO/ 

CODE “CONTROL  1 / 

LOCATION =10. » -2.62,0./ 

EMBEDDED  PLANE'3/ 
eASE  VERTEX “2/ 

CCDE=CCNTS0L2/ 

LOC AT  I ON  = 10. 03, -C. 97.0./ 

EMBEDDED  PLANE=5/ 

BASE  VERTEX*3/ 

EYE  REFERENCE  POINTS/ 

LOCATIONS.  0,2. 0,3.3/ 

NAME«PILOT/ 

TASK  SEQUENCES/ 

SE0UENCE=SECUENCE1/ 

secparm=a/ 

TASK  NUMBER* 1 / 

TASK  DESCRIPTION-STANDARD  POSITION/ 

HAND  CONTROL  C OD E S • FC S T K R P A F T , F CC AT G / 

EYE  CONTROL  CODE'FIADI/ 

FOOT  CONTROL  COCE S = RUDPD R ANUT » R UDP 0 L ANUT / 

HAND  GP I P CODES=3,3 / 

OUR  AT  ION  TIME-1. 0/ 

HOLDING  TIMC«1.C/  . 

EULER  ANoLES  = 90.,90.»180.,90.,90.,90.,A5.,90.,180.*  90.»9T',,-1BC./ 
SEQUENCE -SECUENCE2/ 

5E  CPARM- B / 

TASK  NUMBER =1/ 

TASK  OESCR  IPT  KU  -MCVE  LANDING/ 

HAND  CONTROL  COCE S « F C S T K R P AF T , F CL OGGR 0 *N/ 

EYE  CONTROL  COOt«t-TLDGGRPCS/ 

FOOT  CONTROL  COCE S* RUD POR ANUT , RUDPDL ANUT / 

HAND  GRIP  C00ES=3,I / 

DURATION  TIME-1.0/ 

HOLDING  TIME* 1.0/ 

EULEP  ANGLESe9O.,90.flfi0.,120.,60.*-90.»<i5.,9O.,lMO.,A5.»R0.»-l30./ 
CONTPOL  SHAPES-CONTRCLS/ 

NAME-MAIN  INSTRUMENT  PANEL/ 

PLANE  BOUND/ RIES-1,5/ 

NAME  *L  E F T HAND  CONSOLE/ 

PLANE  BOUNDA1’ IES*9,t  / 

OUMP/ 

ENO  OATA  BANK  EDITOR/ 

CATEGCRY  2 


G-l 


6 RECORD 


88 


3 

2 

0 

0 

0 


6 PECCPO  89 

2 
1 
0 
0 
0 


6 RECORD  90 

1 

10  i 
0 
0 
0 

8 END  ' ' ' ' 

BEGIN  Rt!ttCi-t£0- CUT-PUT/ 
PUNCH*CGEOATA/ 

codata*list/ 

eye  reference  POINT»PILOT/ 


COO AT  A PUNCHED  OUTPUT 


1 

1.000  2.000  3.300 

1PI10T 

PLANES  CNE  AMO  TWO 


2 

PLANEl 

1.00 

PIANE2 

.00 

CONTROLS 


2 

CONTROL! 

C0NTRCL2 


1 3 


1.00 

1.00  2.00 

2.00 

2 

2.00 

2 

.00  2.00  .00 
ONE  AND  TWO 

l.OC 

l.CO 

10.930 

-2.620 

.000 

3 2 

10.930 

-.970 

.000 

5 3 

CONTROL  SHAPES-LIST/ 


2.00  1 


2 

MAIN  INSTRUMENT  PANEL  1 5 

* LEFT  HAND  CONSOLE  9 8 

TABLE  NAME  • 

TASK  SECUENCES-LIST/ 


TASK  SECUENCE  OATA 

TA8LE  NAME  * TASKSEQAA7 

1 

1 STANDAPO  POSITION 

FCSTKPPaPTFCCATG  FIADI  RUDPORANUTRUDPDL ANUT3  3 1.000 

SO  90  180  90  90  90  95  90  180  90  90  -180 

TABLE  NAME  * 


TASK  SEQUENCE  OATA 

TABLE  NAME  « TASKSEQBA7 

l 

1 MOVE  LANDING 

FCSTKRPAFTFCLOGGPDKNFILOGGPPOSRUOPCF ANUTRUDP0LANUT3  1 1.0°0  1.000 

90  90  180  120  60  -90  95  90  180  95  90  -180 

TABLE  NAME  * 

ENO  PUNCHED  OUTPUT/ 

BEGIN  REPORT  SENEP  ATOP / 

REPORT  *CC£  DATA/ 


CGE  COCKPIT  PL  A Nc  OATA 


CREW  STATION  NAM=  . »7£ 


COCKPIT  PLANE  OESCor°TaR 


PLANES  ONE  AND  TWO 


PLANE  NAME  • PL  AN  El 
PLANE  NUMBER  • 1 

VERTICES  * 1.0000  1.0000  1.0000  2.0C00  2.0CC0  2.C 


fa 


PLANE  NAPE  ■ PLANE2 
PLANE  NUMBER  • 2 

VERTICES  . * .0000  .0000  2.0000  .0000  1.0000  1.000 

C6E  EYE  RFFPRENCF  POINT  OATA 

- - CREW  STATION  NAM=  « ATE 

EYE  REFERENCE  POINT  NAME  ■ PILOT 

LOCATION  • 1.0000  2.0000  3,’OOQ 

CGE  COCKPIT  CONTROL  * OATA 
CREW  STATION  NAME  ■ AT£ 

COCKPIT  CONTROLS  OF'CRIPTOR 

CONTROLS  CNE  AND  T*0 


CONTROL  CODE 
LOCATICN 

« C0NTR0L1 
• 10. <5300 

-2.62CO 

.0000 

EMBEOOEO  PLANE 

* 3 

BASE  VERTEX 

» 2 

CONTROL  COOE 

* C0NTR0L2 

LOCATION 

» 10. <5300 

-.9700 

.OCOG 

embedded  PLANE 

* 5 

BASE  VERTEX 

- 3 

G-4 


CGE  TASK  SEQUENCE  DATA 
CREW  STATION  Name  . i7£ 
COCKPIT  TASK  DESCRIPTOR 

SEQUENCE1 

TASK  SEQUENCE  NUMBER  *A 


F 


TASK  NUMBER 
TASK  DESCRIPTION 
RIGHT  HAND  CCNTPOL  CGDE 
tEET  HAND  CONTROL  CODE 
EYE  CONTROL  CODE 
RIGHT  TOOT  CONTROL  CODE 
LETT  FOOT  CONTROL  CODE 
RIGHT  HAND  GRIP  CODE 
LEFT  HAND  GRIP  CODE 
TASK  DURATION  TIMF 
HOLD  TIME  AT  END  OF  TASK 
RIGHT  HAND  EULER  ANGLES 
LEFT  HAND  EULER  ANGLES 
RIGHT  FOOT  EULEP  ANGLES 
LEFT  FOOT  EULER  ANGLES 


SEOUENCE2 


If 


TASK  NUMBER 
TASK  DESCRIPTION 
RIGHT  HANO  CONTROL  CODE 
LEFT  HANO  CONTROL  C CO E 
EYE  CONTROL  CODE 
RIGHT  FOOT  CONTROL  CODE 
LEFT  FOOT  CONTROL  CODE 
RIGHT  HANO  GRIP  CODE 
LEFT  HANO  GRIP  CODE 
TASK  OUR  A T I ON  TIME 
HOLO  TIME  AT  END  OF  TASK 
RIGHT  HANO  EULER  ANGl ES 
LFFT  HAND  EULER  ANGLES 
RIGHT  FOOT  EULEP  ANGLES 
LEFT  FOOT  EULER  ANGLES 


1 

STANOARG  POSITION 

FCSTKRPaFT 

FCCATG 

FIADI 

RUDPDRANUT 

RUOPDLANUT 

3 

3 

l.OCOO 

1.0000 

90. COCO  90. COCO  l°O.0Cr'>1 

90.0CC0  90. COCO  9C.D',C'' 

A5.00C0  90. COCO  toO.COCO 

90.0COO  90.0000  -1 


COCKPIT  TASK  DESCRIPTOR 


TASK  SEQUENCc  N'JMnco  = 9 


1 


MOVE  LANDING 

FCSTKRPAFT 

FCLDGGRDwN 

fildggrpgs 

RUDPDRANUT 
RUOPOL  ANUT 
3 

I 

1 .0000 
1.0000 
90.0000 

90.0000 

1^0. ooco 

120.00C0 

60.0000 

-90 . onoo 

95.0000 

90.0000 

IPO. OOCO 

95.0CCO 

90.00C0 

-1PC.0M0D 

G-5 

COCKPIT  CONTROL  SHAPES  DATA 
COCKPIT  CONTROL  SHAPES  OESCRtPTOR 

CONTROLS 

' CREW  STATION  NANF  • A7g 


CONTROL  SHAPES  NAME  » MAIN  INSTRUMENT  PANEL 
UPPER  PLANE  BOUNDARY  * 1 

LOWER  PLANE  BOUND AR  Y * 5 


CONTROL  SHAPES  NAME  * LEFT  HAND  CONSOLE 
UPPER  PLANE  BOUNOAR  Y - 9 

tOWER  PLANE  BOUNOARY  • 8 


END  REPORT  GENERATOR/ 
END  CAFES/ 
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Purpose  - 1-32 
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Purpose  - 1-23 
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Sub-Models  - 1-15 

CREW  STATION  GEOMETRY  EVALUATION  (CGE) 
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Purpose  - 1-34 
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Objectives  - 1-26 
Purpose  - 1-26 
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FUNCTION  ALLOCATION  MODEL  (FAM) 
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Technology  Assessment  - 1-13 
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HUMAN  OPERATOR  SIMULATOR  (HOS) 

Development  - 1-203-204 
Functions  - 1-38 
Objectives  - 1-38 
Purpose  - 1-36 

INPUTS/OUTPUTS,  SUMMARY  II-4 

INTRODUCTION  - 1-10-39,  II-l 
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DMS  11-107-121  See  DMS,  Description 
FAM  11-77-95  See  FAM,  Description 
WAM  11-95-107  See  WAM,  Description 
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PROGRAM  DESCRIPTION  - I I- 3 

PROGRAM  DESIGN 

ADSTAR  11-69-71 
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Criteria  11-68,  69 

DATA  Flow  11-71 
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